We've watched dozens of internal developer platforms get built with real budget and genuine enthusiasm, then quietly abandoned within a year. The pattern is consistent enough that we now treat it as a design constraint rather than a surprise.
Why platforms get abandoned
Most failed IDPs share one root cause: they were built for the platform team's mental model, not the application engineer's daily workflow. A golden path that requires learning a new abstraction for every task competes directly with the shell scripts a team already trusts — and the shell scripts usually win.
- The platform solves the platform team's problems, not the users'.
- Onboarding a new service takes longer than doing it by hand.
- There is no obvious owner when something breaks at 2am.
Treat the platform as a product
The IDPs that survive have a product manager, a roadmap driven by user interviews, and honest adoption metrics. We start every engagement by shadowing three teams for a week and writing down every command they run to ship a change. That transcript, not a reference architecture, becomes the backlog.
An internal platform earns adoption the same way any product does: by being faster than the alternative on the very first try.
Make the golden path the fast path
The single feature that drives adoption is a self-service scaffold that takes an engineer from an empty repository to a running, observable service in minutes.
$ idp new service --template go-api
✓ repo created, CI wired, dashboards provisioned
✓ staging deploy live in 4m12sWhen that command is genuinely faster than copying a neighbouring team's config, adoption stops being something you have to mandate. Measure success by how many teams reach for the platform without being told to — everything else is vanity.