Why platforms fail on adoption, not technology
The catalog is empty, the templates are stale, and engineers route around the platform the moment it slows them down. A field guide to the anti-patterns that kill IDPs before the tech ever gets blamed.
Post-mortems on failed Internal Developer Platforms almost never say "the technology didn't work." Crossplane provisions infrastructure fine. Backstage renders a catalog fine. What actually happens is quieter: the catalog goes stale, the templates fall behind, and engineers who tried the golden path once and hit friction just... stop using it, and go back to doing things by hand. Nobody announces the platform failed. It just becomes something a smaller and smaller fraction of the org bothers with.
The anti-patterns, named
- Platform-as-side-project. No dedicated team, no roadmap, no one whose job it is to notice when a template breaks. It dies quietly, the same way any internal tool dies when maintenance is nobody's explicit responsibility.
- Big-bang platforms. A year of building before any team can use anything. By the time it ships, the org's needs have moved, the original sponsors have changed roles, and the platform launches into a political vacuum instead of a waiting audience.
- Mandated adoption without a working golden path. Compliance without trust. If the "supported" way to do something is slower or more painful than doing it manually, a mandate produces workarounds and reporting theater, not actual adoption.
- Tool sprawl mistaken for capability. Adding another tool to the stack isn't the same as removing a decision from an engineer's day. A platform team can ship a lot of tooling and still not reduce anyone's cognitive load if none of it composes into a single paved road.
None of these are technology problems. They're product-management and organizational problems wearing infrastructure costumes.
Treat DevEx like a product, because it is one
The fix is to apply the same rigor to internal developer experience that a good product team applies externally: talk to your users — the engineers — define personas, run an actual roadmap, measure adoption and satisfaction, and kill capabilities nobody uses. A platform without a product owner degrades into an unmaintained internal tool no matter how good the initial engineering was, because nothing internal survives without someone whose job is to keep it relevant.
Start from a golden path, not a portal
A portal is a side effect of doing this right, not the goal. The actual product is the paved road from "I have an idea" to "it's running in production," with the org's guardrails already built in — one template that provisions a service, its pipeline, and its infrastructure, with sane defaults and an escape hatch for the minority who genuinely need one. Owned and versioned like any other product, not treated as a one-time scaffolding exercise.
Make infrastructure an API, not a skill requirement
This is where the tooling choice actually matters, but only in service of the adoption goal. With something like Crossplane, infrastructure becomes a set of APIs a template calls. A developer asks for a database through a form; they don't have to learn Terraform to get one. Every time the platform requires a new skill instead of removing one, it's adding friction back in under a different name.
Measure the thing that actually funds the platform
Time-to-first-deploy, change lead time, and toil removed are the numbers that keep a platform team's budget defensible quarter over quarter. The last one — toil removed — is what the ROI calculator converts directly into money: the number a finance review actually accepts, because it's built from measured friction rather than a technology roadmap nobody outside engineering can evaluate.
The pattern across every one of these failure modes is the same: a platform that optimizes for what's technically elegant instead of what an already-busy engineer will actually reach for on a Tuesday afternoon. Adoption isn't a lagging indicator you check at the end — it's the spec.