Building an app marketplace that outlives its launch party means treating it as a two-sided market, not a features checklist: recruit developer supply on purpose, prove customer demand before you scale listings, and enforce quality gates that stop the long tail from rotting. Connector count is vanity. Installs, retention, and partner revenue are the signals that actually compound.
Quick answer: A healthy app marketplace is a two-sided market — developer supply and customer demand growing in lockstep — protected by tiered quality gates that filter out abandoned or low-value apps. Connector count is a vanity metric; active installs, renewal rates, and partner revenue are what tell you the ecosystem is alive.
Why Connector Count Is a Vanity Metric
A big number on a homepage tells you nothing about whether partners are earning money, customers are solving real jobs, or half the catalog still works. A marketplace with 3,000 apps and a 20% dead-link rate is weaker than one with 300 apps that all still function and get used.
Connector count becomes a vanity metric the moment leadership starts treating it as a goal instead of a byproduct. Sales wants "500+ integrations" on a comparison chart. Marketing wants a logo wall. Neither of those pressures asks whether an app was updated last quarter or two years ago, whether anyone has installed it in the last ninety days, or whether the developer behind it is still answering support tickets.
That's the same failure mode Gartner has flagged in its research on integration sprawl and "citizen integrator" programs: organizations that optimize for the number of connections built, rather than the health of the connections in use, end up with brittle, undocumented sprawl that costs more to maintain than it delivers in value. A marketplace is just integration sprawl with a storefront in front of it if nobody is watching the maintenance side.
Symptoms of a Connector Graveyard
You can usually spot a rotting marketplace before you can prove it with data:
- Dead OAuth tokens or broken authorization flows on install
- Listings last updated more than a year ago with no changelog
- Zero reviews, zero visible install counts, or suspiciously round numbers
- Multiple near-duplicate apps competing for the same job with no differentiation
- No revenue share, support SLA, or other incentive for a developer to keep maintaining the app
If you're building or reviving a catalog, this is the core discipline covered in the marketplace PM role guide — treating the marketplace as a product with its own health metrics, not a static directory bolted onto the platform.
The Metrics That Actually Matter
Swap "connector count" for a scorecard that tracks:
- Weekly active installs per category, not lifetime cumulative installs
- 90-day retention of installed apps (uninstall rate is the marketplace's churn number)
- Partner-reported revenue or activation lift, self-reported but directionally useful
- Search-to-install conversion, which exposes discovery and trust gaps
- Time-to-first-value after install, a proxy for onboarding quality
None of these show up on a "we have 1,000 integrations" slide, and that's exactly why they're the ones worth tracking.
The Two-Sided Marketplace Lens
An app marketplace is a two-sided market where developer supply and customer demand have to grow in lockstep. Over-index on one side and you get either an empty shelf nobody can browse or a directory full of apps nobody trusts enough to install. Treat supply recruiting and demand merchandising as two separate roadmaps with their own metrics and owners.
This is the classic chicken-and-egg problem of any platform business, and it's why the best marketplace teams borrow a trick from consumer platforms: make the core product work in "single-player mode" before layering on the network. Investor and writer Chris Dixon's framing — products that "come for the tool, stay for the network" — applies directly here. Customers should get value from your platform's native functionality first; the marketplace is the layer that turns single-player value into a compounding network.
Supply Side: Recruiting Developers Who'll Stick Around
Developers don't build for a platform because a submission form exists. They build because the economics and the tooling make it worth the maintenance burden. Growth-and-network-effects firm NfX has argued that most marketplace failures trace back to under-investing in the supply side until demand has already proven the market exists — chasing splashy demand-side growth while supply quietly stagnates.
A supply-side roadmap worth funding includes:
- Clear, published revenue-share terms — ambiguity here is the single biggest reason serious developers walk away
- Sandbox environments and SDKs that don't require reverse-engineering your API from documentation gaps
- A published review-turnaround SLA, not an indefinite "we'll get back to you"
- Co-marketing slots for partners who hit quality and adoption thresholds
- Migration support and advance notice when your platform's own APIs change
This is where the integrations PM role and the marketplace PM role overlap most directly: someone has to own the developer relationship end to end, not just the listing page.
Demand Side: Proving Customers Actually Want the App
On the customer side, the job is discovery and trust, not just inventory. Categorize apps by the job a customer is hiring them for — "get paid faster," "sync inventory across channels" — instead of by technical integration type. Surface ratings, verified-customer badges, and install counts prominently, and feature apps editorially in underserved categories rather than treating the directory as a flat, alphabetical list.
Before onboarding a new supply category, validate demand exists:
- Check support-ticket and community-forum volume for the job in question
- Run a smoke test — a waitlist or a manual pilot with two or three partners
- Confirm the job shows up in win/loss notes or churn interviews, not just anecdotes
- Only then open a formal call for developer submissions in that category
Curation vs Quantity: Slack, Atlassian, and Shopify Compared
Slack, Atlassian, and Shopify sit at different points on the curation-versus-quantity spectrum, and each illustrates a different failure mode and fix. Slack optimized early for breadth and inherited a stale long tail. Atlassian built revenue-sharing and tiered certification in from the start. Shopify scaled first and retrofitted quality gates after merchant complaints piled up.
| Marketplace | Growth strategy | Primary quality gate | Known trade-off |
|---|---|---|---|
| Slack App Directory | Broad, low-friction submission to maximize breadth of listings | Baseline security and OAuth-scope review at submission | Many apps go stale post-launch with no ongoing health check, weakening trust in the "still maintained" signal |
| Atlassian Marketplace | Curated growth paired with revenue-sharing incentives for vendors | Cloud Fortified certification covering reliability, security, and support responsiveness | Slower on-ramp for new vendors, but a materially higher average app quality and vendor retention |
| Shopify App Store | Scale-first, opened widely to independent developers early on | Built for Shopify program, introduced in 2023 to raise the performance and UX bar | Merchant complaints about review turnaround and inconsistent app quality preceded the fix |
Atlassian's Cloud Fortified badge is worth studying closely: apps have to clear thresholds for uptime, in-app support response time, and update cadence to earn it, and losing the badge is a real, visible consequence, not a one-time stamp. Atlassian has publicly framed its marketplace as a shared revenue engine with third-party vendors, which gives the company a durable reason to keep the certification bar credible instead of letting it become a rubber stamp.
Shopify took the opposite path. It opened its app store aggressively to grow the catalog fast, which worked for reach but let quality variance creep in — some apps slowed storefronts, others duplicated functionality, and merchants noticed. Built for Shopify was Shopify's response: a certification layer, retrofitted after the fact, that rewards apps meeting explicit performance, design, and support standards with better placement.
Slack sits closer to the "list of connectors" end of the spectrum discussed at the top of this piece. Its directory has historically leaned on baseline security review rather than an ongoing, tiered certification program, and it shows in the number of listings that look abandoned. That's not a knock on Slack's product — it's a reminder that curation is an investment decision, and a platform without a strong revenue-share or certification lever has fewer tools to keep vendors accountable after launch.
The lesson isn't "always curate harder." It's that curation intensity should match what your team can actually operate. A five-person marketplace team should lean on automated gates. A well-resourced one, like Atlassian's or Shopify's, can afford editorial curation and named certification tiers — but only if it builds them deliberately rather than bolting them on after the graveyard is already visible. Getting the review pipeline itself right is partly a security problem, and the practices in the security PM role guide are a useful pairing for anyone designing that gate.
Designing Quality Gates That Scale
Quality gates work when they're tiered, automated wherever possible, and paired with real consequences — delisting, demotion, or a required update — not a single review at submission and nothing after. Build separate gates for onboarding, for ongoing health, and for gracefully retiring apps that go abandoned.
| Gate | When it applies | What it checks | Typical mechanism |
|---|---|---|---|
| Entry gate | At submission | Security review, OAuth scope justification, basic UX and policy compliance | Manual or semi-automated review, days not weeks |
| Health gate | Ongoing, quarterly or annual | Uptime, install-to-uninstall ratio, support responsiveness, API version currency | Automated monitoring plus a lightweight scorecard |
| Sunset gate | On decline | Zero recent installs, broken auth, no maintainer response within an SLA window | Auto-delist or an explicit "unmaintained" flag on the listing |
The health and sunset gates are the ones most marketplaces skip, and they're the ones that actually prevent the graveyard. An entry gate only tells you an app was fine on day one. Automated health checks — watching for broken webhooks, deprecated API version usage, or install-to-uninstall ratios that spike — catch the slow decay an entry gate can't.
Building that monitoring layer is genuinely a platform-infrastructure problem: webhook reliability, API versioning, and deprecation notices all sit squarely in infra PM territory, and it's worth scoping the health gate alongside whoever owns that plumbing rather than treating it as a marketplace-team-only initiative.
Vertical marketplaces raise the bar further. A fintech app marketplace handling account or payment data has to layer compliance and data-handling review on top of the standard gate — a topic the fintech PM role guide covers in more depth, and one reason payment-adjacent marketplaces tend to move slower on developer onboarding than horizontal ones like Slack's.
The Flywheel: How Supply, Demand, and Quality Compound
A marketplace flywheel is the reinforcing loop where quality apps attract more customers, more customers attract more capable developers, and more developers raise the average quality bar further — but the loop only spins if every handoff between those stages is instrumented and owned.
Platform theorist Sangeet Paul Choudary, in his writing on platform design, frames a platform's core job as three functions: pulling in participants, facilitating a match between them, and enforcing rules that keep the exchange trustworthy. Curation is that third function. Skip it, and the first two eventually break too — customers stop trusting the pull, and the match gets noisier as low-quality listings crowd out good ones.
The loop, stated plainly:
Quality apps → customer trust and installs → partner revenue → better developer supply → higher average quality → back to the start.
Neglect the quality node and the loop runs backward: a graveyard of dead apps erodes trust, trust erosion suppresses installs, suppressed installs starve partner revenue, and serious developers leave for a platform that still enforces its own standards.
If you're reviving a marketplace that's already stalled, a few moves reliably restart the flywheel:
- Freeze low-bar new submissions temporarily and run a full quality audit of the existing catalog
- Delist or clearly flag apps that fail the sunset gate — silence here is worse than an honest label
- Re-launch your top categories organized around jobs customers actually hire the platform for, not integration mechanics
- Fund or co-market a flagship partner in every category where supply is thin
- Publish a public roadmap of upcoming platform capabilities so serious developers can plan ahead, rather than reacting to undocumented changes
Framing the Marketplace Around Jobs, Not Logos
Customers don't browse a marketplace to count logos. They arrive with a job to be done — "get paid faster," "reconcile inventory across channels," "route support tickets automatically" — and a marketplace organized around those jobs, rather than around integration mechanics, converts better and reveals real supply gaps.
This is where Jobs to Be Done thinking earns its keep. Tony Ulwick's Outcome-Driven Innovation method scores opportunities by combining how important an outcome is to the customer with how underserved it currently is, which is a far more useful lens for a marketplace roadmap than "which integrations do our biggest accounts keep asking for." A job with high importance and low satisfaction is where your next supply-recruiting push should go — regardless of whether a flashy logo is attached to it.
Prodinja's Customer Jobs tool is built for exactly this reframe. It walks a PM through JTBD-style interviews and Ulwick-style opportunity scoring, so a marketplace roadmap ends up organized around the jobs partners and customers are hiring the platform for — not whichever integration happens to have an internal sales champion pushing it. For an ecosystem PM, that means testing whether "sync inventory in real time" or "get paid faster" is genuinely underserved before deciding which three connector categories to actively recruit into, instead of reverse-engineering categories from whatever apps already showed up in the queue.
Categorizing by job also does double duty for supply-side recruiting: a public "jobs we're underserved on" list is a far better developer-acquisition pitch than a generic "submit your app" form, because it tells a prospective partner exactly where the demand-side gap is.
Key Takeaways
- Connector count is a vanity metric. Weekly active installs, 90-day app retention, and partner revenue are the signals that show an ecosystem is actually alive.
- Treat the marketplace as a two-sided market. Fund supply-side recruiting (revenue share, tooling, SLAs) and demand-side merchandising (job-based categories, ratings, featured placement) as separate roadmaps.
- Curation intensity should match operating capacity. Atlassian's
Cloud Fortifiedand Shopify'sBuilt for Shopifyshow two credible but different investments; Slack's broader, lighter-touch model shows the trade-off of skipping ongoing certification. - Build three gates, not one: an entry gate at submission, a recurring health gate, and a sunset gate that delists or flags abandoned apps.
- The flywheel only compounds if the quality node is instrumented. Skipping it turns the loop into an accelerant for churn instead of growth.
- Organize the catalog around jobs to be done, not integration mechanics — it improves customer discovery and gives developers a clearer signal of where to build next.
Frequently Asked Questions
What's the difference between an app marketplace and an integration directory?
An integration directory is a passive list of connections a platform supports; an app marketplace is an active two-sided product with its own economics — developers earn revenue or distribution, customers get discovery and trust signals, and someone owns ongoing quality. If nobody is accountable for delisting dead apps or recruiting into underserved categories, you have a directory wearing a marketplace's branding.
How many apps does a marketplace need before it's viable?
There's no fixed number, and chasing one is the mistake this article warns against. Investor Bill Gurley's writing on marketplace liquidity is more useful here: what matters is whether a customer searching for a job gets a good, working match, not how large the total inventory is. A marketplace with a hundred well-maintained apps that reliably solve the top twenty customer jobs beats one with a thousand apps and thin coverage of any single job.
How do you clean up a marketplace that's full of dead connectors?
Run a full audit against a sunset gate — checking for broken auth, zero recent installs, and unresponsive maintainers — then delist or clearly flag everything that fails it. Pair the cleanup with a relaunch of your top categories framed around customer jobs, so the smaller, cleaner catalog reads as a curation upgrade rather than a shrinkage.
Should a marketplace charge developers or take a revenue share?
Most successful B2B marketplaces use a revenue-share model in a similar ballpark to consumer app store norms, rather than upfront listing fees, because it aligns platform and developer incentives around ongoing usage instead of a one-time submission. Revenue share also gives the platform real leverage to enforce quality gates, since a developer earning money has more reason to maintain an app than one who paid a flat fee and moved on.
Who owns marketplace quality — the platform PM or the individual product teams?
Marketplace quality needs a single accountable owner, typically an ecosystem or marketplace PM, even though the gates themselves draw on security, infrastructure, and individual product teams. Without one owner responsible for the health and sunset gates specifically, quality work becomes everyone's second priority and nobody's first — which is exactly how a catalog turns into a graveyard in the first place.