Building an internal developer platform teams actually use
We built an IDP that cut our deploy time from 40 minutes to 4. Here's the architecture, the golden paths, and the mistakes we made first.
Every engineering org eventually hits the same wall: developers spend more time fighting the deployment pipeline than writing features. When we audited one client's workflow, a single service change took 40 minutes and touched six different tools. An internal developer platform (IDP) fixed that.
An IDP isn't a product you buy — it's a thin layer of self-service on top of your existing infrastructure. The goal is simple: a developer should be able to ship a service to production without filing a ticket or learning Kubernetes.
Golden paths over guardrails
The core idea is the "golden path" — an opinionated, paved road for the 80% of cases. A developer picks a template, fills in three fields, and gets a repository, CI pipeline, observability, and a production deployment wired up automatically.
- Scaffolding: a CLI generates the service from a vetted template.
- CI/CD: pipelines are inherited, not copy-pasted.
- Observability: logs, metrics and traces are on by default.
Crucially, the platform is optional. Teams with unusual needs can drop down to the raw infrastructure. The platform earns adoption by being faster, not by being mandatory.
What we got wrong first
Our first version was too rigid — it assumed every service looked the same. Adoption stalled until we added escape hatches. The lesson: a platform that can't be bypassed will be resented; one that can be bypassed but rarely needs to be will be loved.
Six weeks after rollout, deploy time dropped to four minutes and the platform team stopped being a bottleneck. That's the whole point.