Every platform faces the same bootstrapping problem. Developers don't build on empty marketplaces. Customers don't buy subscriptions to platforms with no extensions. The flywheel described in the anchor piece of this series is self-reinforcing once it's moving — but getting it moving in the first place requires attracting developers before you have the scale to justify the investment. That's the developer acquisition problem, and solving it is what separates platforms with thriving ecosystems from the ones with app stores nobody uses.
The tactics exist. They've been tested at scale by Shopify, Atlassian, HubSpot, and Stripe. None of them are complicated in principle. Most platforms still get them wrong.
Treat 0% revenue share as an acquisition budget, not a discount
The most direct lever for attracting developers early is revenue share design — specifically, what share the platform takes during the period when a developer is trying to find product-market fit. As covered in the $4 economy piece, the platforms with the strongest flywheels have consistently made the same choice: take nothing, or near nothing, from developers in their early stage.
HubSpot charges 0% revenue share from App Marketplace partners in perpetuity. No listing fee. No cut. The result: 1,700+ integrations, and an average of more than 9 apps installed per customer. Almost all HubSpot customers have at least one third-party app installed; more than half have five or more. That attach rate didn't happen because HubSpot's product was inadequate. It happened because HubSpot made it economically rational for developers to build deep, niche integrations — the kind that serve small customer segments and would never be viable with a 30% revenue cut baked in.
Shopify and Atlassian have arrived at similar positions through slightly different paths. Shopify charges 0% on a developer's first $1 million in lifetime App Store earnings. Atlassian introduced 0% on the first $1 million in lifetime Forge revenue as an explicit incentive to bring developers onto their hosted execution platform. In both cases, the logic is the same: the long tail of specialist developers building niche tools for niche segments can't afford the economics of high revenue shares. Lowering the cost of building is how you get them to build.
The framing that matters is this: 0% revenue share is not a financial concession. It is a developer acquisition cost, calculated deliberately, in the same way a sales organisation budgets for customer acquisition. The ROI is measured not in immediate take-rate but in app volume, attach rate, and the compounding value of an ecosystem that keeps growing without requiring continuous subsidy.
Invest in white-glove programs before you need to
When Shopify launched its App Store in 2009, it was a cost centre by design. The team knew that organic developer growth wouldn't happen without investment in relationships. They offered prizes and direct financial support to the first cohort of developers. They made time for individual conversations. Bold Commerce — then a four-person team — received the kind of attention that turned them into a reference case for what was possible on the platform. They grew to more than 300 employees, over 760,000 merchant installs, and $5 billion in facilitated GMV. The white-glove treatment was the seed investment.
Atlassian formalised this model over time. Their Marketplace Partner Program structures developer relationships into tiers, with Partner Development Managers assigned to Gold and Silver partners to provide hands-on guidance, co-marketing access, and early visibility into the platform roadmap. In 2024 and 2025, Atlassian reinstated and expanded PDM coverage in response to partner feedback that mid-tier developers weren't getting enough direct support — a telling sign of how seriously they take the relationship model.
White-glove programs serve two functions that are easy to underestimate. First, they convert early builders into advocates. A developer who had a substantive conversation with someone at the platform, got a real answer to a hard technical question, and saw their app featured in a merchant education article is more likely to build a second app than one who filed a support ticket and waited two weeks. Second, they generate the case studies and ecosystem stories that make the next cohort of developers believe the platform is a serious bet. You can't manufacture those stories. You have to earn them.
Make documentation the first product your developers ship with
Developer experience (DX) is where most platform teams underinvest, because the failures are invisible. A developer who couldn't figure out how to authenticate against your API doesn't file a complaint — they close the tab and go build on a different platform. You never see that drop-off in your support queue.
Stripe became the reference case for documentation quality not by accident but by enforcing a specific cultural rule: a feature is not shipped until its documentation is written, reviewed, and published. That discipline — treating docs as a ship requirement rather than a post-launch task — has a compounding effect. Documentation that is accurate, interactive, and structured around real working examples reduces the time from sign-up to first integration. Every developer who gets to "it works" faster is more likely to continue building. Every one who hits a wall disappears.
The practical implication for platforms building developer programs is that documentation quality is a conversion funnel, not a support resource. The question worth measuring is: what percentage of developers who access your API documentation ship something within 30 days? If that number is low, the bottleneck is almost certainly in the docs, not in the API itself. Stripe's documentation became an industry benchmark because they invested in it as a product with its own roadmap, its own metrics, and its own dedicated team — before they were large enough to afford not to.
Use hackathons to create first-mover momentum
The developer acquisition problem is fundamentally a cold-start problem. Before you have a marketplace with thousands of apps and proven merchant demand, you have to convince developers to take a bet on an ecosystem that doesn't yet exist. Prize-driven hackathons are one of the most effective tools for accelerating that initial momentum.
Virtual hackathon participation grew 150% in 2024 compared to traditional in-person events. Platforms from Atlassian to Meta to Zoho run structured hackathons specifically to drive first-use of new extension frameworks and SDKs. The mechanism is straightforward: a developer who builds a proof-of-concept for a hackathon has already invested the time to learn the platform. That knowledge doesn't disappear after the competition ends. The best hackathon designs leverage this — requiring use of specific APIs or SDK features, so that the prize structure effectively funds a developer onboarding programme.
First-mover incentives beyond prizes also matter. Platforms that offer early developers elevated marketplace placement, co-marketing opportunities, or access to beta features before general availability give developers a reason to move now rather than wait until the ecosystem is de-risked. The developer who builds first gets the early-mover advantage in the marketplace — which is a real and meaningful incentive when the alternative is competing against 500 established apps for the same search terms.
The sequence matters as much as the tactics
These tactics — 0% revenue share, white-glove programs, documentation investment, and hackathon momentum — work in a specific sequence. You can't compensate for poor documentation by offering better revenue share. You can't generate case studies without individual relationships. You can't create first-mover incentives once the first movers have already moved.
The failure modes that kill platform ecosystems often stem from getting the sequence wrong: extracting revenue share before developers have found product-market fit, treating documentation as a cost to minimize, or running hackathons without the SDKs and docs in place for participants to succeed. Each of those mistakes undermines the others.
The platforms that have built durable developer ecosystems made most of these investments before they could see the return. Shopify spent years treating the App Store as a cost centre before the flywheel started producing returns that justified the investment. HubSpot committed to 0% revenue share before it had the ecosystem scale that made the model obviously correct in retrospect. That sequencing — investing early, sustaining through the pre-critical-mass period — is what created the compounding advantage that competitors are still trying to replicate.
Developer acquisition is not a marketing problem. It is a platform design problem, a product quality problem, and a relationship investment problem. The best platforms treat it as all three — and they start before the numbers justify it.