The extensibility flywheel doesn't emerge from good intentions. It emerges from a specific set of architectural and strategic decisions made at the right time, in the right order, and maintained consistently enough that developers start to trust the platform with their livelihoods. Getting those decisions right is what separates the platforms that built compounding ecosystem advantages from the ones that built app directories nobody uses.
This is the most practitioner-focused piece in this series. If the anchor post made the case for why the flywheel matters and the previous piece covered the failure modes, this one is about the decisions themselves — what to build, in what order, and why each dimension matters.
Surface area: what you open and how
The flywheel starts with surface area — the collection of extension points, APIs, and hooks you expose to third-party developers. More surface area isn't automatically better. The question is whether the surface area you expose is where developers can add genuine customer value.
Shopify has invested heavily in the concept of hosted execution — running third-party code inside Shopify's own infrastructure rather than making developers maintain external services that integrate via webhooks. Shopify Functions, built on WebAssembly, lets developers customise checkout logic — pricing, discounting, shipping calculations — running directly in Shopify's stack. The difference from a developer's perspective is enormous: no server to maintain, no reliability concerns, just logic that runs where the platform runs.
Atlassian's Forge framework took the same direction. Rather than requiring developers to host their own apps and authenticate via OAuth callbacks, Forge provides a hosted execution environment. The tradeoff is some constraints on what you can build. The benefit is that Atlassian controls the runtime, can guarantee security and performance standards, and — critically — can offer 0% revenue share on the first $1 million in earnings as an incentive to adopt the hosted model. Hosted execution aligns the platform's and developer's interests: Atlassian gets security and quality guarantees; developers get free infrastructure and distribution.
Developer experience: the investment that compounds
Surface area is necessary but not sufficient. APIs that are poorly documented, SDKs that behave inconsistently, or review processes that take three weeks and reject submissions without explanation will kill developer interest faster than any competitor can.
Developer experience (DX) is where most platform teams underinvest, because it produces no direct revenue and its failures show up as absence rather than visible complaint. Developers don't file bug reports about confusing documentation. They just go build on a different platform.
The platforms with strong flywheels have typically treated DX as a product with its own roadmap, its own metrics, and its own dedicated team. Stripe's developer documentation became an industry benchmark not because Stripe got lucky but because they invested in it as a competitive differentiator from the beginning. Documentation that reduces the time from sign-up to first working integration by even a day compounds over thousands of developers — and developers who had a good onboarding experience are substantially more likely to recommend the platform to peers.
Distribution: the marketplace as a product
If developers can build excellent extensions but customers can't find them, the flywheel doesn't spin. Distribution — how customers discover, evaluate, and install extensions — is as important as the extension ecosystem itself, and it requires sustained product investment that most platforms treat as an afterthought.
Marketplace discovery is a search and recommendation problem. It requires structured metadata, quality signals (install counts, ratings, recency of updates), and category taxonomies that match how customers think about their problems. It requires surfacing new apps that are high-quality before they've had time to accumulate reviews — which is a cold-start problem that needs an explicit solution, not a hope that good apps will find their own audience.
The platforms that have done this well treat marketplace placement as a form of distribution subsidy for early-stage developers. Shopify's editorial curation, featuring apps in merchant education content, and embedding app recommendations in the core product setup flow all reduce the barrier to discovery in ways that compound over time.
Monetisation design: sequencing the extraction
How and when a platform takes its share of developer revenue is one of the most consequential decisions in ecosystem design — and one of the most frequently mismanaged.
The pattern that works is consistent across the platforms with strong flywheels: aggressive 0% or near-0% revenue share at the early stage of a developer's growth, transitioning to a standard take rate once the developer has established distribution and revenue. Shopify's 0% threshold on a developer's first $1 million lifetime earnings. Atlassian Forge's 0% while the hosted framework is gaining adoption. HubSpot's 0% in perpetuity.
The logic isn't charity. It's a calculated investment in developer acquisition. The long-tail developer building a specialist tool for a niche segment doesn't have the margin to absorb a 30% revenue cut while they're still finding product-market fit. If the platform takes that cut early, those developers don't build. And the long tail is where most of the ecosystem value eventually comes from — not the top 20 apps, but the 2,000 apps that each serve a specific segment well.
Ecosystem health: the metrics that matter
Most platform teams track app count. Few track the metrics that actually indicate flywheel health.
Attach rate — the percentage of customers who have installed at least one third-party extension — is the most important leading indicator. It tells you whether the ecosystem is adding value that customers feel. A stagnating attach rate while app count grows is a warning sign: the marginal apps aren't solving real problems.
Developer retention — whether developers who shipped one app go on to build a second — tells you about the quality of the platform as a home for developer businesses. Platforms with low developer retention are extracting value from developers without returning it.
Revenue concentration — how much of total ecosystem revenue flows to the top 10 or 100 apps — tells you about fragility. An ecosystem where two apps account for half the revenue is one acquisition away from a governance crisis.
These are the metrics worth building a dashboard around before the flywheel is fully spinning. They're the difference between discovering problems early, when you can still fix them, and discovering them late, when the damage is already structural.
The flywheel is a design problem. Open the right surfaces. Invest in DX like it's a product. Treat the marketplace as distribution infrastructure. Sequence monetisation to reward developer risk-taking. Measure the things that tell you whether the flywheel is actually working, not just whether it looks like it might be. None of this is simple. All of it is tractable. And the platforms that have worked through it consistently — Shopify, Atlassian, Salesforce — have built something that most of their competitors have spent a decade trying to replicate and can't.