An internal developer platform (IDP) helps teams build, deploy, and support software without repeatedly navigating infrastructure tasks and handoffs. Its purpose is a better developer experience: less extraneous work and cognitive load, so stream-aligned teams can spend more time delivering product enhancements. An IDP supports independent value streams; it does not replace the need for well-defined domain boundaries. section 13.0 section 1.2.1
An IDP is a shared internal capability for teams building products. Unlike a domain platform, which provides reusable business capabilities such as booking, it provides capabilities for developing and supporting those products. Sharing work can bring economies of scale, but a platform becomes a bottleneck if its capabilities are hard to consume or cannot keep up with teams’ needs. The test is not whether tooling has been centralized; it is whether teams can use it with less friction. section 6.1.4 section 13.1.2
Shape the platform around common tasks and make the preferred route easy to follow:
- Offer golden paths for tasks such as creating an application and deploying it. Expose capabilities through an interface suited to the task, such as a UI, CLI, configuration, or Git-based workflow. section 13.6 section 13.2
- Make development and operations self-service where possible: application setup, deployment to test and production, and access to metrics, monitoring, logging, and other observability. section 13.1.2 section 13.6
- Keep applications discoverable and documentation usable. An application catalog can show ownership; clear instructions let consumers complete routine tasks without opening support tickets. section 13.6 section 13.2.5
- Build security and compliance into the route to production. Pipeline checks can scan code, confirm review and test deployment, and retain an audit history rather than relying on developers to remember every control. section 13.2.6
Self-service application setup at HMRC
HMRC’s Multi-channel Digital Tax Platform supported around 60 distributed development teams in 2015. A developer could run a Jenkins job with an application name and type; it created a Git repository containing an application skeleton and platform conventions. A few lines of configuration established build and deploy pipelines, metrics, monitoring, and logging. This illustrates what a golden path can remove: repeated setup and requests to other teams before work can reach production. section 13.1.5
Connecting developer experience to business flow
At La Redoute, creating a service fell from weeks to minutes, and the time from commit to production fell from days to under ten minutes. Its platform work prioritized built-in quality and an incremental developer experience rather than starting with a fully featured portal. The useful question is which delays and quality problems a platform should remove for its consumers—not which portal to build first. section 13.3
Treat the IDP as a product, not a multiyear project delivered all at once. Define the value it should provide, compare it with existing and off-the-shelf options, start with a small viable capability, and refine it through consumer feedback. Staff it for sustained work: as adoption grows, platform work cannot remain an incidental duty. If multiple teams own different layers, align them around the consumer’s end-to-end experience so internal handoffs do not become everyone else’s bottleneck. section 13.4.1 section 13.4.2
Consider developer experience early in modernization, but build only enough platform to deliver the first slice. A thin path to production may emerge through close work between platform and software engineers; where that path carries substantial uncertainty, establish it with a proof of concept. A few teams may not need an IDP at all, particularly when existing or off-the-shelf solutions suffice. Revisit the decision as team numbers, support load, and adoption prospects change. section 16.2.3 section 13.5 section 13.6
