Build less platform than you think

Every failed internal developer platform we have been called in to look at died the same way: it was finished before anyone used it.

The pattern is consistent. A platform team forms, gathers requirements from every engineering team, and disappears for three quarters to build the complete vision — service catalogue, golden templates, self-service everything, a portal with the company logo on it. By the time it ships, the product teams have solved their problems some other way, the platform answers last year’s questions, and adoption becomes a programme of persuasion. Persuasion is what you need when the product is not pulling people in on its own.

Platforms are products, and products start small

The teams that succeed treat the platform as a product with exactly one feature at launch: a paved road from commit to production for the most common kind of service in the company. Not every kind. The most common kind.

That paved road needs to be genuinely better than what teams do today — faster, safer, with observability included — for the 80% case. It can be useless for the other 20%. This feels wrong to platform engineers, who are completists by temperament. It is the single most important discipline in the practice.

One way to keep yourself honest is to write the platform’s scope as a list of things you will not do, and make the list public:

# platform v1 — explicitly out of scope
- stateful workloads          (run them where they are)
- GPU / batch jobs            (revisit when >2 teams ask)
- non-HTTP services           (revisit when >2 teams ask)
- bespoke per-team pipelines  (the paved road is the product)

“Revisit when more than two teams ask” is the load-bearing phrase. It converts roadmap arguments into a measurable signal, and it means every platform capability that exists was pulled into existence by demand rather than pushed by ambition.

The portal is the last thing you build

Backstage is good software. It is also where platform efforts go to feel productive while shipping nothing that changes a team’s day. A catalogue of services nobody deploys through is a museum.

The honest sequencing test: would a product team notice if your platform disappeared tomorrow? Until the answer is “our deploys would stop working,” you have not built a platform; you have built tooling adjacent to one. Pipelines first. Templates second. The portal when there is something worth a portal.

Adoption is the only metric that matters early

We advise platform teams to track one number for the first year: the percentage of production deploys that go down the paved road. Not satisfaction surveys, not feature counts. If that number is rising without mandates, the platform is working. If it needs a mandate to rise, the platform is not better than what it replaced — and the mandate is hiding that information from you.

Mandates also corrupt the feedback loop. A team forced onto the platform files tickets; a team choosing the platform tells you what would make them choose it harder. The second conversation is the one that designs your roadmap.

What this means in practice

When we build platforms with clients, the first production deploy through the paved road happens inside the first month — one pilot team, one service, real traffic. Everything after that is widening: more service shapes, more teams, capabilities added strictly in demand order. The platform is never finished, and that is the point. Finished platforms are abandoned platforms with better documentation.

Build the road. Skip the city. The city builds itself around a road people actually use.