Internal developer platforms that aren't treated as products become expensive maintenance burdens. The four anti-patterns we see repeatedly — and how to avoid them.
The best-intentioned platform teams fall into the same traps repeatedly. They build what they find technically interesting rather than what engineers actually need. They measure platform adoption by the number of services onboarded rather than by the reduction in cognitive load experienced by the teams they serve. They underinvest in documentation and onboarding because the platform team already knows how it works.
Platform engineering succeeds when it is treated as a product discipline with real users, a real backlog, and real success metrics measured from the user's perspective. The technical work is straightforward — Backstage, Crossplane, and ArgoCD are well-documented. The product discipline is the hard part.
The fix is product thinking, not technical work. Assign a product owner to the platform. Run quarterly developer experience surveys. Define golden paths per service archetype. Automate catalog validation in CI. Measure adoption by outcomes, not outputs.
Author: CELESDEV Solutions — Cloud & Platform Practice. Based on IDP design and adoption programmes serving 200–1,200 engineers.