There's a graveyard at every large company. It's full of internal platforms that were going to fix everything — until the engineers they were built for quietly went back to writing their own infrastructure. We've been on both sides of this story, and the failure modes are remarkably consistent.
Why most platforms fail
- They're built for managers, not engineers. Dashboards, reports, approval flows — none of which an engineer needed.
- They optimise for control, not flow. Adding friction is easy. Removing it without losing safety is the hard problem.
- They have no users on the team building them. A platform team without product-engineer empathy ships features nobody asked for.
- They never delete anything. Every feature stays forever, and the surface area becomes its own debt.
Principles that actually work
- Golden paths, not gates. Make the right way the easy way. Keep the escape hatch.
- Treat the platform as a product. Real PM, real research, real shipped milestones — not a roadmap doc.
- Measure adoption, not coverage. 'We have a service' is meaningless. 'Eighty per cent of new services start here' is everything.
- Self-service or it doesn't exist. If an engineer has to file a ticket, the platform failed.
- Documentation is part of the product. Not a wiki, not a Confluence page nobody opens. A first-class artefact, owned and maintained.
The shape that's winning right now
Internal Developer Platform on top of Kubernetes or serverless, with a thin Backstage-style portal, golden paths for the five or six common service shapes, security and compliance gates that run inline rather than as quarterly audits, and — increasingly — agentic copilots that automate the operational toil that used to consume your platform team's afternoons.
What we bring
We've built platforms for fast-growing scale-ups and for global enterprises modernising thousand-service estates. The bar is the same in both cases: developers using the platform by choice within six months, and the platform team scaling sub-linearly with the org.