[DRAFT — AWAITING APPROVAL]
Internal Developer Platforms: What Engineering Teams Actually Need
Most IDP initiatives start with a portal. The successful ones start with the paths behind it.
An internal developer platform (IDP) is the set of tools, workflows and guardrails that let engineers build, deploy and run services without filing tickets or rebuilding infrastructure for each team.
Start with the journeys, not the portal
Many IDP efforts begin by installing a developer portal. A portal is an interface; it only helps if the paths behind it are reliable. Map the journeys engineers repeat most — creating a service, getting an environment, shipping a change, debugging production — and fix those first.
What teams actually need
- Golden-path templates that produce a working, deployable service on day one
- Self-service environments with sensible defaults for networking, secrets and access
- One standard delivery path: CI, GitOps-based deployment and progressive rollout
- Observability, security scanning and cost tagging included by default, not bolted on
- Clear ownership and documentation for every platform capability
Build thin, then thicken
A thin platform that wraps existing tools (Terraform modules, Helm charts, CI templates) with consistent interfaces is usually more valuable than a large bespoke system. Add abstraction only where teams repeatedly struggle.
Measure adoption, not features
Useful signals include time to first deployment for a new service, the share of services on golden paths, lead time for changes and the volume of platform-related support requests. If engineers route around the platform, treat that as product feedback.