· 4 min read

Platform Maturity Model: From ClickOps to Self-Service

Most platform teams don't have a tooling problem. They have a maturity problem. Here's a practical five-stage model for where your platform sits and what it takes to move forward.

Platform EngineeringKubernetesStrategy
On this page
  1. The Five Stages
  2. The Mistake Most Teams Make
  3. How to Use This
  4. The Takeaway

Most platform teams don’t have a tooling problem.

They have a maturity problem - and they’re solving it with the wrong tools.

The question isn’t which IDP to adopt or whether to use Backstage. The question is where your platform actually sits and what the honest next step looks like.

The Five Stages

Stage 1 - ClickOps

Everything is manual. Infrastructure is provisioned through cloud consoles. Deployments happen through scripts that live on someone’s laptop. The platform team is the platform.

This isn’t always a problem. Early-stage teams move fast here. The issue is staying here past the point where it slows everyone down.

Signs you’re here: deployments require a specific person; there’s no repeatable path to production; knowledge is tribal.


Stage 2 - Scripted

Automation exists, but it isn’t standardised. Shell scripts, Makefiles, and one-off pipelines get the job done - inconsistently. There’s a Kubernetes cluster. Maybe two. CI/CD is in place for some teams but not all.

The platform team has stopped clicking - but they’re still in the critical path because the scripts only work if you know how they work.

Signs you’re here: onboarding a new service takes days; each team has a slightly different deployment process; the platform team gets pulled in regularly to debug pipelines they didn’t write.


Stage 3 - Tooled

The platform looks mature from the outside. Kubernetes everywhere. ArgoCD or Flux. A shared observability stack. Probably a Terraform monorepo.

But there are no golden paths. Everything is bespoke. The platform team maintains dozens of slightly different configurations across dozens of teams. Self-service is a roadmap item that never lands.

This is where most platform teams are stuck. They have all the tools. They don’t have a product.

Signs you’re here: the platform team is the single point of failure for any non-trivial change; adding a new service requires a platform team member to copy-paste a template; the Kubernetes upgrade backlog is growing.


Stage 4 - Paved

Golden paths exist. There’s a standard way to deploy a service, provision a database, and manage secrets. New teams can follow the path without asking the platform team for help.

The platform team is mostly out of the critical path for routine operations. They’re still pulled in for edge cases and new capability requests - but that’s appropriate.

Most organisations that reach this stage are in a good position. The work from here is refinement, not reinvention.

Signs you’re here: onboarding a new service takes hours, not days; the platform team’s ticket volume has dropped; developers use the golden path because it’s genuinely easier than going around it.


Stage 5 - Self-Service

The platform is a product. Developers provision infrastructure, deploy services, manage environments, and debug production issues without platform team involvement.

The platform team’s job is to build and improve the product - not to operate it on behalf of others. They measure success by developer productivity, not by tickets closed.

This is achievable. It’s not common.

Signs you’re here: the platform team could take a week off without developer workflows breaking; the internal developer platform has an actual roadmap driven by developer feedback; most operational requests are handled by automation, not humans.


The Mistake Most Teams Make

Skipping stages.

Stage 3 teams buy Stage 5 solutions. They implement Backstage before they have consistent golden paths. They build a developer portal on top of inconsistent infrastructure and wonder why adoption is low.

The tooling isn’t the problem. The foundation is the problem.

A service catalogue built on top of three different deployment models is still three different deployment models - just with a nicer UI.

The path forward is always the same: consolidate before you build; standardise before you automate; automate before you self-serve.

How to Use This

Find your stage honestly. Not aspirationally.

The test is simple: can a developer on your platform - without asking the platform team - deploy a new service to production end-to-end?

If no, you’re at Stage 3 or below, regardless of what’s in your stack.

The next step isn’t a new tool. It’s removing whatever is in the way of that developer completing that workflow alone.

The Takeaway

Maturity isn’t about having the right tools. It’s about having a platform that works without the platform team in the room.

Most organisations are at Stage 3. The investment that moves them to Stage 4 isn’t large - it’s focused. Identify the one or two workflows that most frequently pull the platform team into the critical path, and build a golden path for those first.

That’s the lever. Everything else follows.

If you want an honest read on where your platform sits and what the realistic next step looks like, we can help.

Frequently Asked Questions

What is a platform maturity model?

A platform maturity model is a framework for assessing where an engineering platform sits on a spectrum from fully manual operations to full developer self-service. It helps teams understand what they have, what they're missing, and what the next meaningful step looks like.

What are the stages of platform engineering maturity?

The five stages are ClickOps (fully manual), Scripted (ad hoc automation), Tooled (CI/CD and Kubernetes in place but no golden paths), Paved (golden paths exist but the platform team is still in the critical path), and Self-Service (developers complete routine operations without platform team involvement).

How do I know what stage my platform is at?

The clearest signal is how often the platform team sits in the critical path for routine developer operations. If developers can't deploy a service, create an environment, or provision infrastructure without opening a ticket, you're at Stage 2 or 3 regardless of how sophisticated your tooling is.

How long does it take to reach platform engineering maturity?

Moving up a single stage typically takes three to six months with focused effort. The most common mistake is trying to skip stages - investing in developer portals before golden paths exist, or building self-service on top of inconsistent infrastructure.