Stop trying to build a platform. Build a tool.

Platforms need ecosystems. Tools need one user with one problem.

Every indie founder has the same inflection point. The product works for a handful of people. Usage is growing. And then the thought arrives: "What if we opened this up? What if other people could build on top of it? What if we became the platform?"

That thought has killed more promising products than bad code, bad marketing, and bad timing combined.

The platform trap

A tool solves a problem. A platform hosts other people's solutions to other people's problems. The difference in engineering effort, go-to-market strategy, and operational complexity is not 2x. It's 10x or more.

When Shopify was a tool, it helped merchants set up online stores. When it became a platform, it needed an app ecosystem, a developer relations team, an API stability guarantee, a review process for third-party apps, documentation for external developers, a partner program, and a fraud detection system for apps that abuse merchant data. Each of those is a company-sized problem on its own.

Shopify pulled it off because they had hundreds of millions in revenue and thousands of employees when they made that transition. They didn't start as a platform. They earned the right to become one.

Most indie products try to skip directly to platform. They add plugin systems before they have 100 users. They build APIs before anyone has asked for one. They design extensibility frameworks before the core product is stable. Then they spend six months maintaining infrastructure that nobody uses while the core experience rots.

Tools have gravity. Platforms have overhead.

A good tool attracts users because it solves their problem right now. No ecosystem required. No third-party developer community needed. Someone finds it, tries it, and either it works or it doesn't. The feedback loop is fast.

A platform attracts users only when the ecosystem around it has enough value to justify the switching cost. That's a chicken-and-egg problem that burns time and money. You need developers to build apps before users will adopt the platform, but developers won't build apps until there are users. Solving this requires either subsidizing developers (expensive) or building the first wave of apps yourself (which means you're back to building tools anyway).

The tool path: build something, ship it, get users, charge money. Six weeks to first revenue if the product is good.

The platform path: build something, build the developer tools around it, write documentation, recruit developers, hope they build things, hope users find those things. Twelve to eighteen months before the ecosystem generates value, if it ever does.

For a solo founder or small team, the platform path is almost always wrong. Not because platforms aren't valuable. Because you can't afford the timeline.

The premature API

The most common form of platform thinking in early-stage products: building an API before anyone has asked for one.

APIs are expensive to maintain. Once external developers depend on your API, every endpoint becomes a contract. Changing a response format breaks someone's integration. Deprecating a field requires a migration path. Version management becomes a permanent line item in your engineering budget.

If you have 50 users and zero of them have asked for API access, you don't need an API. You need a better core product. The time spent building and documenting an API could have gone toward fixing the three things your actual users complain about.

Build the API when someone emails you saying "I need to integrate this with my system and I'll pay more for it." That's demand. Everything before that is speculation.

The plugin system nobody uses

Same pattern. A product with 200 users adds a plugin architecture. Now the codebase has a plugin loader, a sandboxing layer, a configuration schema, and documentation for plugin developers. Total plugins written by external developers: zero.

The plugin system exists because the founder imagined an ecosystem. Not because users asked for extensibility. The fantasy is compelling: other people building features for your product, for free, that attract more users. In practice, plugin ecosystems only work at scale. WordPress has plugins because it has millions of sites. Figma has plugins because it has millions of designers. Your product with 200 users does not have the gravity to attract plugin developers.

Build the ten features your users actually need instead of building a system for other people to maybe build features someday.

When to actually become a platform

There are real signals that a product should add platform capabilities:

Users are building workarounds. They're scraping your UI, exporting CSVs and transforming them in scripts, or building unofficial integrations. This means the core product has value but doesn't connect to their workflow. An API makes sense here because the demand already exists.

Power users are asking for customization that would fracture the core product. If adding every custom request would turn the product into an unmanageable mess, a plugin or extension system lets power users solve their own edge cases without bloating the main product.

Revenue supports the investment. Platform infrastructure is ongoing cost. API maintenance, developer support, documentation updates, backwards compatibility testing. If the business can't absorb that cost for 12+ months with no direct revenue from the platform layer, it's too early.

A third party offers to build on top of your product and pay for the privilege. This is the clearest signal. Someone with money wants to extend your product for their own commercial purposes. That's real demand.

Everything else is founder fantasy about what the product could become if it were ten times bigger. Build for what it is now.

The tool-first path

Build a tool. Make it good. Charge for it. Get to the point where the tool generates enough revenue and has enough users that platform capabilities become a natural extension rather than a premature bet.

Basecamp was a project management tool for years before it became anything resembling a platform. Notion was a note-taking tool before it had an API. Linear was an issue tracker before it had integrations. Each of them nailed the core experience first. The platform layer came later, funded by tool revenue, pulled by user demand.

There's a version of your product that solves one problem really well for a specific group of people. That version is shippable in weeks, not months. It doesn't need an app store or a developer portal or an API reference. It needs to work, reliably, for the people who have that specific problem.

Ship that. Everything else is a distraction dressed up as ambition.