Internal Developer Platform

An Internal Developer Platform (IDP) is the set of self-service tools, templates and APIs that let product teams build, deploy and operate services without waiting on another team.

Platform as a product

The mindset shift is treating internal developers as customers. A platform team that works like a product team does user research, keeps a roadmap, measures adoption and earns usage, rather than mandating it.

Self-service is the point. If developers need to ask someone, it’s not a platform; it’s a service desk with extra steps.

Typical capabilities

• Service scaffolding (Golden Paths)
• CI/CD and environments
• Infrastructure provisioning, often through infrastructure-as-code modules
• Secrets management and access control
• Observability wired in by default (Observability)

Common building blocks: a developer portal such as Backstage, a service catalogue, templates, and an orchestration layer over cloud APIs.

The planes

A useful way to see an IDP is as many technologies and tools glued together so they lower developers’ cognitive load, without hiding the context and the technology underneath. It usually splits into planes:

• Control plane: makes sure services and resources are set up and stay that way, typically through an orchestrator such as Kubernetes.
• Service plane: runs the things app teams consume, such as an application runtime or a CI/CD pipeline.
• Management plane: the self-service front door. Often a portal like Backstage, but a CLI, an API or even a Slack integration counts.
• Identity: an IDP normally plugs into the organisation’s identity and access management, so people get single sign-on with fine-grained permissions.

The phrase I keep coming back to is “without abstracting away context”. A platform that hides everything turns into a black box nobody can debug.

The Team Topologies framing

In Team Topologies, stream-aligned teams deliver product value and a platform team exists to reduce their cognitive load by providing internal services. The default interaction is X-as-a-Service, with short facilitating phases while a team onboards.

That cognitive-load lens is also how to decide what to build: platform the supporting capabilities every team repeats, buy the generic ones, and leave the core alone. See Where Platforms Fit: DDD Subdomains.

Measuring success

If the platform is working, delivery gets faster and safer. Lead time and deployment frequency should improve as friction drops, without change failure rate rising. That’s what DORA Metrics measure. Adoption, and what developers say in surveys, are the product metrics.

In practice

The closest I’ve come is building a low-code workflow platform: templates and reusable building blocks that let workflow designers ship new automation without writing a service each time. Same principle, different audience. The lesson that carried over: the platform’s real competitor is “we’ll just build it ourselves”, and you only beat that by being genuinely easier. More in Building a Low-Code BPMN Workflow Platform.

Looking further back, the self-service portal, Web Accelerator and shared components I built at Elanco were a small IDP for websites before I knew the term (Building a Web Platform for 80 Sites).