Platform engineering has moved from a niche discipline to a mainstream engineering function. Every organization with 50+ engineers is building some version of an internal developer platform (IDP). Most of them fail to achieve meaningful adoption.
After building IDPs for a dozen enterprise clients, here are the patterns that drive adoption — and the anti-patterns that kill it.
Start with a golden path, not a menu
The most common mistake is building an IDP that offers maximum flexibility. Platform teams present developers with a menu of 15 different deployment options and expect them to choose. Developers choose the path of least resistance: doing whatever they were doing before.
Successful IDPs offer one opinionated golden path that covers 80% of use cases. The remaining 20% is handled by escape hatches — ways to deviate from the golden path with explicit acknowledgment of the tradeoffs.
Platform teams are product teams
The IDPs that get adopted are run like products. They have internal customers, SLAs, product roadmaps, and regular user research. The teams that treat their IDP as a technical project — shipping features based on what's technically interesting — consistently fail.
Observability is table stakes
Developer experience is only as good as the observability available to developers. An IDP without built-in observability — logs, metrics, traces, dashboards — forces developers to solve problems outside the platform. Once they leave, they often don't come back.