A maturity model for internal developer platforms
Not every team needs a full internal developer platform on day one. Here's a five-stage way to think about where yours is today, and what the next step actually looks like.
Internal Developer Platform is often used to describe one specific thing, a Backstage instance with a service catalog, but that's really the end state of a maturity curve, not the starting point. Most organizations are somewhere earlier on that curve, and the right next investment depends on knowing where.
Level 0: tribal knowledge
There's no platform, just documentation scattered across wikis, chat threads, and whoever's been on the team the longest. Onboarding a new engineer takes weeks because the real process for provisioning a service or getting access to a database lives in someone's head.
Level 1: documented, still manual
The process is written down, runbooks exist, there's a checklist for spinning up a new service, but every step is still done by hand. This is a real improvement over level 0, and a lot of teams stay here productively for a long time. The failure mode is documentation drifting out of date as the underlying infrastructure changes.
Level 2: golden paths and templates
A new service starts from a template that already has CI/CD, observability, and security scanning wired in, rather than being built up manually from a blank repo. This is usually the highest-leverage single investment on the whole curve, because it turns doing the right thing into the path of least resistance instead of something that has to be remembered and enforced.
Level 3: self-service provisioning
Developers can provision infrastructure, a database, a queue, a new environment, through a form or CLI without opening a ticket to another team. This removes the platform team as a bottleneck for routine requests, which is usually the point where platform engineering starts paying for itself in velocity, not just consistency.
Level 4: full portal with ownership and catalog
A service catalog exists, ownership is tracked, cost and health are visible per service, and the platform itself has become a product with users and a roadmap. This is where Backstage-style tooling actually fits. Building it before levels 2 and 3 exist usually produces a nice-looking catalog with nothing useful behind it.
The right question for most teams isn't how to get to level 4, it's what the next level actually looks like from where they are today. Skipping straight to a full portal without golden paths or self-service underneath it tends to produce a lot of platform team effort with very little developer-facing improvement.