The Internal Developer Platform (IDP) has become the architectural response to a well-understood problem: as organisations scale their engineering capability, the cognitive load on individual teams grows unsustainably. Every team must understand Kubernetes, CI/CD pipelines, cloud networking, secrets management, observability tooling, and a dozen other infrastructure concerns — in addition to the actual product they are supposed to be building.
Platform engineering offers an alternative. A dedicated platform team builds and maintains a set of shared capabilities — the "golden paths" — that abstract away infrastructure complexity and let application teams focus on delivering business value. In theory, this is an elegant solution. In practice, most platform engineering programmes fail to deliver the promised velocity improvement, and often create new bottlenecks in place of old ones.
The difference between successful and failed platform engineering programmes almost always comes down to one thing: whether the platform is treated as a product or as a project.
The Product Mindset
An infrastructure project has a defined scope, a delivery date, and a handover. Once it is built, the project team moves on. A platform product has customers — the application teams who use it — and it exists to serve their needs continuously. This distinction is not semantic. It changes everything about how the platform is designed, measured, and evolved.
A platform team with a product mindset talks to its customers regularly. It measures developer experience — how long does it take to provision a new environment? How many steps are required to deploy an application? What is the error rate on platform APIs? These metrics drive the platform roadmap. The platform is good when application teams find it easier to use than to work around.
A platform team without a product mindset builds what it thinks developers need, based on its own infrastructure preferences. It measures uptime and capacity. It does not have a developer experience team. It is surprised when teams build shadow infrastructure to avoid using the official platform.
The Golden Path Problem
The "golden path" metaphor is attractive but dangerous. The implication is that there is one right way to do things, and the platform's job is to make that way easy. In reality, the diversity of application types, languages, deployment models, and team conventions means that a single golden path serves some teams well and others poorly.
The platform needs to support a small number of well-maintained paths — perhaps three or four for the most common use cases — while not creating so much friction for teams who fall outside those paths that they are forced to work without platform support at all. This requires deliberate decisions about what the platform owns and what it does not own.
The platform should own the concerns that are genuinely shared — networking, secrets management, observability pipelines, base container images. It should not own the concerns that differ by team — application deployment frequency, feature flag strategy, or database schema management.
The Internal Developer Portal
The surface through which developers interact with the platform is increasingly the Internal Developer Portal (IDP portal) — distinct from the Internal Developer Platform itself, though the acronym collision is unfortunate. Tools like Backstage provide a unified interface for discovering services, spinning up environments, understanding dependencies, and accessing platform documentation.
A well-designed portal dramatically reduces the cognitive overhead of using platform capabilities. But a poorly designed portal — one that is incomplete, out of date, or that routes developers into ticket queues rather than self-service workflows — adds frustration rather than removing it. The portal is a product too, and it requires the same investment in design and maintenance as the underlying platform.
Platform as Enablement, Not Control
The most common failure mode for platform engineering programmes in large organisations is that they become a mechanism of control rather than enablement. The platform team becomes a centralised gatekeeper — approving infrastructure requests, reviewing configurations, and enforcing standards through manual processes.
This is the opposite of what platform engineering is for. The platform should enforce standards through automation — guardrails that prevent non-compliant configurations from being applied, not review gates that slow down compliant teams. The platform team's job is to make compliance the path of least resistance, not to police non-compliance.
- Implement standards as code (policy-as-code, infrastructure templates) not as approval workflows
- Measure developer experience metrics alongside reliability metrics
- Treat adoption rates as a leading indicator of platform health
- Invest in self-service capabilities before investing in sophistication
- Maintain a team API — clear boundaries of what the platform team owns and what it does not
Getting the Architecture Right
The architecture of an Internal Developer Platform needs to balance two concerns: consistency (so that guardrails can be applied and support can be provided) and flexibility (so that teams are not forced into patterns that do not fit their context). These concerns are in genuine tension, and the platform architecture needs to make deliberate choices about where each wins.
In practice, this often means a layered architecture — a mandatory foundation layer (identity, networking, logging, secrets management) that all workloads must use, and optional capability layers that teams can adopt as they see value. The foundation layer is non-negotiable. Everything above it is a golden path offering, not a requirement.
Ergotech helps organisations design platform engineering architectures that balance enablement with governance. Get in touch to discuss your platform strategy.