A platform is a product, not a wiki of links
An Internal Developer Platform (IDP) brings tools, templates, and documentation together into a single self-service interface. The key word is product: it has an owner, users — developers — and a success metric: how fast an engineer takes an idea to production. A portal that nobody runs as a product dies within six months — I'll come back to that.
The core pain an IDP removes is cognitive load. A developer on a single microservice today is expected to hold Kubernetes manifests, Terraform, ArgoCD, Vault policies, Prometheus rules, and Kyverno policies in their head all at once. The platform hides this behind self-service: press a button, get an environment.
Why now: three drivers
1. DevOps without structure doesn't scale. The "every team is its own DevOps" model works with three teams and breaks at thirty: each one assembles its own zoo of tools and the organisation drowns in fragmentation. A platform restores consistency without killing autonomy.
2. AI code outruns governance. Agents and Copilot write code faster than manual code review can validate it. The only scalable answer is to move control into automated guardrails: policy-as-code as admission control, rather than a human reviewer as the bottleneck.
3. Cognitive load has become unbearable. This follows from the first two: the more tools and the faster the flow of change, the costlier it is to keep everything in your head. An IDP gives the developer back their focus on their own service.
Per CNCF, 28% of organisations already have a platform team; Gartner forecasts 80% of large enterprises by the end of 2026. This isn't hype — it's a structural answer to complexity.
The canonical six-layer stack
A working platform on Kubernetes is assembled from six layers. I stick to CNCF-native defaults — not because they're the only right choice, but because they cohere: the tools are built to work together.
- 1. Developer Portal — Backstage: a single UI, catalog, scaffolder.
- 2. GitOps & Deployment — ArgoCD or Flux: declarative delivery.
- 3. Infrastructure Provisioning — Crossplane: infrastructure as K8s resources.
- 4. Policy & Security — Kyverno and Trivy: guardrails and scanning.
- 5. Observability — Prometheus, Grafana, OpenTelemetry.
- 6. AI / DevEx — still emerging: assistants and AI-driven incident triage.
Six layers is the minimum. Mature platforms add homegrown admin-API services and AI-assisted triage. But without the first six the superstructure is meaningless. An important caveat: a portal without golden paths and a policy engine is a catalog with no inventory. A bare Backstage delivers no value; the value is in the templates that hand you a repository with CI/CD, observability, and a security baseline at the press of a button — and in the policies that keep that baseline from degrading.
The three pillars of the portal
- Software Catalog — a single source of truth: services, owners, dependencies, runbooks, dashboard links. Not a hand-kept spreadsheet, but automatic discovery.
- Scaffolder — golden paths as code: button → a ready repository with a pipeline, monitoring, and a security baseline.
- TechDocs — docs-as-code from service repositories with unified search.
What to measure
A platform-as-a-product demands product metrics:
- Time-to-first-deploy — from repo creation to production (target: under a day).
- Self-service ratio — the share of tasks solved without going to the platform team.
- Template adoption — the share of new services created through the scaffolder.
- Internal NPS — a developer survey once a quarter.
If adoption is rising while NPS falls, you've built coercion, not a platform.
Four ways to kill an IDP
- A portal with no owner team — nobody evolves it, it dies within six months.
- A scaffolder with no post-create automation — it generated boilerplate but never wired up CI, secrets, and monitoring; the developer ends up at the platform team's door anyway.
- A catalog as a hand-kept spreadsheet — without automatic discovery it goes stale the day it's created.
- Forced adoption — a platform should be the best path, not the only one.
Takeaway
An IDP is an investment in speed and consistency that only pays off with a product mindset: an owner, metrics, and a path people choose voluntarily. The six layers give you the frame; the three drivers explain why delay is expensive; the four anti-patterns show where platforms die. Don't start with the portal — start with one golden path that genuinely saves a developer a day. And the six layers don't have to arrive all at once — add them incrementally, as each prior layer starts to pay off.