Paved roads, not platforms

Internal developer platforms fail when they are built as a destination rather than a service. A platform nobody chooses is a cost center with a roadmap, and most platforms end up there because they were designed around what the platform team wanted to build rather than what the product teams wanted to consume. The result is a system that exists on paper, has a backlog of features nobody asked for, and a compliance mandate keeping it alive long after its usefulness has passed. The failure pattern is predictable. A platform team forms, writes a vision document, and builds a portal. Product teams are told to onboard. Onboarding is slow, the portal does not fit their use case, and a parallel shadow platform grows in shell scripts and Slack channels. Eventually leadership notices adoption is low and issues a mandate. Mandate-driven adoption produces resentment, not velocity, and the platform becomes something teams route around the moment they can.

The pattern that works is the paved road: opinionated templates and self-service paths that make the right thing the easy thing, adopted voluntarily because they are genuinely faster than the alternative. A paved road is not a platform you visit. It is a path you take because it saves you days. The difference between a platform and a paved road is that a paved road competes with the alternative on time, and wins.

Start with one road. The most common new-service setup, with provisioning, CI/CD, observability, and secrets handled, is usually the right first candidate, because every team needs it and the pain of doing it manually is felt broadly. Build that one road well. Measure how long it takes to stand up a service with and without the road, and let the gap do the selling. A team that watches a new service go live in an afternoon, instead of a week, does not need to be mandated to use the road. They ask for it.

Keep the platform team thin. A small team with a clear catalog and good feedback loops will outperform a large team with a mandate, because a small team is forced to prioritize the few things that matter, while a large team can afford to build the things that do not. The catalog should be short, the defaults should be strong, and the escape hatch should be documented. Teams will accept opinionation when they trust the opinions, and trust comes from seeing the road improve in response to real usage. Feedback loops are what separate a living paved road from a static one. When a team uses the road and hits a wall, that wall should become a ticket the same day, and a fix within the week. If feedback disappears into a backlog that is groomed quarterly, the road ossifies, and teams start building their own paths again. The platform team's job is not to build the platform. It is to keep the road faster than the alternative, continuously.

Avoid the trap of generality. A platform that tries to serve every use case serves none well. It is better to have three excellent paved roads that cover the majority of services than one abstract platform that covers everything poorly. The teams whose use case does not fit a road can build their own, and that is fine. The goal is not universal coverage. It is to make the common case effortless, so that the uncommon case has room to be handled deliberately.

Adoption is earned, not imposed. The teams that adopt voluntarily become advocates, and advocates do your onboarding for you. The teams that adopt under mandate become resentful users who will leave at the first opportunity. Build the road, measure the time it saves, publish the number, and let the evidence recruit the next team. That is how a platform becomes infrastructure people are glad to have, rather than a system they are forced to tolerate.