The extensibility flywheel is one of the most powerful structural advantages in software. But it is not self-sustaining. Most platforms that attempt to build an ecosystem never get the flywheel spinning at all. A meaningful number get it moving, then kill it themselves. A smaller number manage to keep it running for a decade or more — and the differences between those outcomes are not accidents.
This piece is about the failure modes. Understanding what breaks a flywheel is more useful than celebrating the ones that are working, because most of the decisions that determine success happen long before the outcome is clear.
Sherlocking: competing with the developers who trusted you
The most damaging thing a platform can do to its ecosystem is build natively what developers have already built on top of it. The practice has a name — Sherlocking, borrowed from Apple's habit of absorbing third-party app functionality into the operating system — and it poisons developer trust in a way that is very slow to recover.
Atlassian has navigated this tension more visibly than most. When they acquired several automation and workflow management apps that had been built by independent developers on their platform, the signal to the rest of the ecosystem was ambiguous at best: build something successful and Atlassian might buy it, or build something successful and Atlassian might build it themselves. That uncertainty is real cost. It changes the risk calculus for developers evaluating where to invest their next two years.
Shopify did something similar with email marketing. Shopify Email launched as a native product in 2020, entering a space where Klaviyo, Omnisend, and dozens of smaller developers had built significant Shopify app businesses. Some of those businesses survived by differentiating on depth and features Shopify wasn't prepared to match. Others didn't. The developers who built on the platform in good faith found themselves competing with the platform itself.
The platforms that have avoided this trap most successfully tend to have an explicit policy about it: Stripe has been consistent about owning the payment rail and leaving everything above it to third parties. Twilio built its business on being the infrastructure layer and not the application layer. The constraint is strategic, not accidental — and developers can see the difference.
Quality collapse: the cost of an unmanaged ecosystem
A flywheel that works by accumulating volume rather than value will eventually self-destruct. More extensions does not automatically mean more customer value. Below a certain quality threshold, more apps creates confusion, erodes trust, and makes the marketplace worse for everyone — customers who can't find what they need, and developers whose good products are buried under noise.
Shopify pruned more than 1,000 apps from its App Store in 2024. That decision deserves more attention than it typically receives. A platform with 16,000 apps willing to remove 6-7% of them on quality grounds is making a statement about what the marketplace is for: not a directory of every extension that has ever been submitted, but a curated distribution channel where quality is the baseline.
The alternative is what BigCommerce demonstrates by contrast. BigCommerce and Shopify share a similar architectural approach to extensibility, but their app ecosystems have diverged dramatically in scale and quality. BigCommerce's marketplace has a fraction of Shopify's volume and significantly lower merchant attach rates. The technical infrastructure was never the constraint. The flywheel velocity gap came from years of different choices about governance, developer investment, and the seriousness with which each platform treated the marketplace as a product in itself.
Quality collapse doesn't look like a collapse at the time. It looks like steady growth in the number of available apps. The signal is the attach rate stagnating, or customer satisfaction with the ecosystem declining, or the best developers quietly moving their next project to a platform that takes governance more seriously.
The governance failure modes
Beyond Sherlocking and quality collapse, there are several more subtle failure modes that stall flywheels before they get moving:
Inconsistent policy enforcement. If the rules about what gets listed, what gets removed, and what revenue share applies change without notice or clear rationale, developers stop making long-term bets on the platform. Trust is an input to developer investment decisions, and it is hard to rebuild once lost.
Treating revenue share as a profit centre too early. Ecosystems die fastest when the platform tries to extract margin before it has earned the right to do so. A 30% cut is affordable when a developer has hundreds of thousands of customers and established distribution. It is fatal when they are trying to reach their first thousand. Platforms that get this sequencing wrong tend to attract only developers with existing audiences who can survive the cut — which is the opposite of what an early-stage ecosystem needs.
Underinvesting in distribution. An extension that can't be found might as well not exist. Marketplace discovery — search, categorisation, recommendation, reviews — is a product in itself, and it requires sustained investment. Platforms that launch a marketplace and treat discovery as a solved problem consistently find that their ecosystem grows to a certain size and stops.
The flywheel requires deliberate design at every stage
The insight the failure modes converge on is this: the extensibility flywheel is not automatic. It doesn't turn because you open an API or launch an app store. It turns — or stalls — based on the cumulative weight of specific decisions made over years.
Decisions about whether to compete with developers. Decisions about when to enforce quality standards and how strictly. Decisions about how to structure revenue share as a function of the ecosystem's maturity, not the platform's short-term margin targets. Decisions about how much to invest in marketplace discovery, developer tooling, and the boring infrastructure that makes building on a platform feel reliable.
The platforms with the most durable flywheels made most of these decisions well, most of the time, over a decade or more. That consistency is harder to replicate than any single architectural choice — which is precisely why it's worth understanding before the mistakes become visible.