Marketplace ecosystem: What Atlassian’s 7,000 apps required

The Atlassian Marketplace lists more than 7,000 apps from more than 2,200 partners, with over 1.4 million installs.¹ That is a functioning economy in which business customers routinely buy software from somebody other than the vendor they already pay.

The mistake is reading that as evidence the pattern is available to you. What Atlassian has is the output of a marketplace that worked, and the input was a customer base large enough, and varied enough, that a third party could build a business on it.

So ask first whether your customers would pay a third party, not whether developers would build. In some categories that is normal and in others customers expect everything from the vendor and read a paid add-on as evidence the product is incomplete. Which of those you are in is knowable, and it is knowable before you build anything.

What is a marketplace ecosystem?

A marketplace ecosystem is a platform where third parties build and distribute extensions to your product, and where customers assemble a configuration you did not design. Of everything in this section it puts the most distance between a customer and the exit, because leaving means undoing work done by companies you do not control, and it is the one pattern where your defensibility is somebody else’s labor.

It is also a two-sided market, with everything that implies. You need developers to attract customers and customers to attract developers, and at the start you have neither: this is the cross-side network effect, which is the strongest kind and by far the hardest to start. That problem does not get solved by an API and a submission form.

The prerequisites, honestly

Five things have to be true, and the first two are usually not.

Your customers’ needs must genuinely diverge. A marketplace is a bet that what people want is more varied than you could ever build. If your customers mostly want the same ten things, the correct answer is to build those ten things. Outsourcing a roadmap you could have shipped yourself is worse than not having a marketplace: it fragments the experience and makes you dependent on strangers for quality.

There must be enough customers to make a living from. A developer weighing your platform is estimating the addressable spend. If your customer base is small, or spends nothing on add-ons, the estimate is zero and no amount of documentation changes it. This is why marketplaces belong to platforms with scale, and why launching one early is a common and expensive mistake.

You must be able to be extended. A product with no meaningful extension points cannot host anything but notifications. If a third party cannot add an object, a step in a workflow, or a surface in your interface, they cannot build anything a customer would pay for. This is the point at which an API worth building against stops being a developer-marketing question and becomes a platform one.

You have to keep the platform stable for years. Every breaking API change costs somebody else money and their users’ goodwill, and developers price that risk in permanently. A platform with a reputation for breaking apps struggles to recruit, whatever the revenue share says, because the maintenance burden is the real cost of building on you.

You have to be willing to compete with your ecosystem, and to lose sometimes. Every successful category on a marketplace is a category you could build yourself, and building it destroys the trust that got developers there. Decide in advance where your product stops. That decision is the deal you are offering developers.

Build the first integrations yourself

Nobody starts with a marketplace. The sequence that works starts with you doing the work, and the reason is not just chicken-and-egg.

Building the first ten integrations yourself is how you find out whether your extension points are usable. You discover the missing webhook, the object that cannot be created via the API, the auth flow that assumes a human. Ship a platform without that exercise and every third-party developer hits the same walls with far less patience and no obligation to tell you.

It also produces the thing developers actually need, which is not documentation but proof that money is being made. The same install counts double as a product-qualified signal about your own customers: an account that has wired in three apps is telling you something no survey will. A handful of well-used integrations with visible install counts is a far stronger recruitment argument than any partner program, because it answers the only question a developer has.

The order, then: your own integrations, until you cannot keep up; then a small number of invited partners, hand-held; then an open marketplace once there is demonstrable demand on both sides.

At the far end of this there is a services layer worth knowing about, because it is a moat of a different kind. Once enough consultants and agencies make a living implementing your platform, and certification in it is worth something on a CV, you have people whose careers depend on your continued relevance. That is harder to replicate than any app directory, and the largest platform ecosystems arguably run as much on people as on software.

The empty-shelf problem

A directory nobody builds for is survivable. A directory that exists and is visibly thin is worse, because it is a public signal and a prospect reads it as a verdict on you. A prospect browsing forty listings with old screenshots and abandoned support links learns something about the platform’s momentum, and it is not what you intended. The same applies to quality: one broken app that loses somebody’s data is attributed to you, whatever the terms say.

There is a second-order version of the same problem. An ecosystem deep enough that leaving means unpicking a dozen vendors is also deep enough to feel coercive, and a customer who experiences your platform as a trap behaves like any other trapped customer: they stop buying more and start saying so out loud. Depth is worth having and it is not self-justifying.

Curation is therefore not optional, and it is the ongoing cost teams forget to budget. Review, delisting, quality standards, and someone whose job is to notice that a popular app has stopped being maintained. A marketplace is a product with its own roadmap, not a page you launch.

Which categories this actually suits

The categories where this works are more numerous than the usual Shopify-and-Salesforce examples suggest, and they have a shape in common. Commerce, where no two merchants operate the same way (Shopify). Systems of record sitting at the center of many workflows (Salesforce, HubSpot). Developer and project tooling, where teams’ processes differ wildly and customers are used to buying tools. Design and creative software with a plugin culture. Accounting and back-office platforms serving businesses whose needs diverge by industry. What all of them share is a large customer base with genuinely divergent needs, and an existing habit of buying software from more than one vendor. What they do not share is a category: this is about the customers, not the software.

Counting apps tells you nothing

Total app count is the vanity metric here. The number worth having is how many different teams inside one account have installed something, and almost nobody tracks it: integrations concentrated in one team can be undone by one person’s decision, while integrations spread across marketing, sales, support and finance are far harder to undo because no single decision-maker owns them all.

Then check the shape of the thing. If the top five apps take most of the installs, you do not have an ecosystem, you have five integrations you did not write and now depend on. If accounts with an installed app do not retain better than comparable accounts without one, at the same tenure and size, the ecosystem is decorative. And count the listings with no update and no support response in a year, because that number is what a prospect is actually browsing.

One question has to be asked of people, not data: is any developer making enough to keep going? If the answer is no, every listed app is quietly losing value and the next cohort will not arrive.

Before you open a directory

1. Read your integration backlog and decide whether it shows variety or repetition. That single judgment tells you whether this pattern is available to you at all.
2. Build the next three integrations yourself, and write down every extension point that was missing. That list is the actual platform work.
3. Find out whether your customers buy third-party software at all. Ask a dozen. If they expect everything from the vendor, stop here and be glad you asked before building a marketplace.
4. Invite a small number of partners before opening anything, and help them personally. Their revenue is your recruitment material.
5. Decide where your product stops, in writing, before anyone builds. The first time you ship a competitor to a popular app without having set that boundary, you lose the ecosystem’s trust and it does not come back.
6. Recommend the second app immediately after the first install. The whole customer-side adoption story is that installs compound: someone who has connected one thing is the likeliest person to connect another, and that is the moment to suggest it. The temptation is to spend everything on recruiting developers and nothing on this.
7. Budget for curation permanently. An unmaintained directory is a liability on your own domain, and it is read as a statement about you.

That completes the ways a product holds on to someone: living where the work happens, returning by reflex where the rhythm allows it, accumulating history worth keeping, growing into depth, and finally becoming a platform other people build on. All of it is retention, and none of it is revenue. A product can be genuinely indispensable and still be free. Turning that into revenue depends on something the whole next section quietly assumes: that people can start using you at all without anyone’s approval, and that somebody inside the company can eventually be found to pay. Bottom-up adoption is the motion everything in Expand is built on.

Updated August 2026