Building a marketplace application looks like a product business with distribution solved. The distribution part is real. The rest of the product business is not solved, and that is where the business case usually falls apart.
The most common origin story is the weakest one: "we built this for ourselves, we may as well sell it." Internal tools encode your specific process, your data model and your assumptions. Making one work for other organisations is typically more work than the original build, and the demand is unproven.
What the business case must cover
| Cost | One-off or ongoing | Frequently forgotten |
|---|---|---|
| Multi-tenancy work | One-off, substantial | Yes |
| Security review preparation | One-off, then per update | Yes |
| Listing assets and documentation | One-off, then upkeep | Partly |
| Customer support | Ongoing, scales with installs | Yes |
| Platform release compatibility | Ongoing | Yes |
| Billing and licence enforcement | One-off plus ongoing | Yes |
| Marketing beyond the listing | Ongoing | Almost always |
A marketplace listing is a shelf, not a sales force. Applications that succeed there are marketed the way any product is marketed; the listing captures demand rather than creating it.
The multi-tenancy tax
This is the largest hidden item. An application built for your organisation assumes things a distributed one cannot:
- Custom fields and objects that exist in your org and nowhere else.
- Data volumes orders of magnitude different from yours.
- Configuration, currencies, locales and regional endpoints that vary.
- Edition differences changing what APIs are available.
- Permission models configured entirely unlike yours.
- Installation and uninstallation being clean, which internal tools never need.
Testing the demand before building it
- Find ten organisations with the problem who are not you. If you cannot, the market may not exist.
- Ask what they do today — a painful manual workaround is a much stronger signal than agreement that the problem exists.
- Ask what they would pay, and watch for hesitation rather than listening to the number.
- Check what already exists on the marketplace, honestly.
- Offer a paid pilot before building the product version. Money changing hands is the only reliable signal.
- Then decide.
Sell it before you productise it. Private packages or bespoke installs for three or four paying customers prove demand, generate revenue and teach you what varies between organisations — which is exactly the knowledge multi-tenancy work requires. Listing afterwards is a much better-informed build.
When the case is strong
Proceed when
- Paying customers exist already
- The problem is common, not specific to you
- You can fund years of support
- Someone owns it as a product
- There is a marketing plan beyond listing
Reconsider when
- It began as an internal tool
- Demand is assumed, not tested
- Nobody will own support
- Mature competitors exist
- The revenue would not fund the maintenance
A model that stays honest
| Line | Assume conservatively |
|---|---|
| Installs in year one | Low double digits at best |
| Conversion of free to paid | A small fraction |
| Churn | Higher than you expect early |
| Support hours per customer | More in the first months |
| Maintenance | A standing engineering cost, not zero |
| Break-even | Later than the optimistic case |
If the model only works at high install counts, it is not a business case — it is a hope. A model that survives conservative assumptions is one you can commit to.
Considering a marketplace application? Tell us the problem and who else has it — we will be straight about whether the case holds. See AppExchange security review and Zoho Marketplace publishing.