The Internal Platform Nobody Uses

Most engineering organisations have built one. A self-service portal, a set of Terraform modules, a CLI wrapper around Kubernetes - Maybe it runs on Backstage or perhaps it is a Confluence wiki with a link to a git repo nobody commits to anymore.

They called it an "Internal Developer Platform" (IDP) but developers are calling it something else, quietly.

The failure mode is almost always the same: a platform team builds tooling for developers, gets no adoption, then spends six months trying to mandate usage through policy rather than earning it through value.

You Built Infrastructure. You Didn't Build a Product.

The core mistake is treating an IDP as an infrastructure project instead of a product project.

Infrastructure teams are optimised for reliability and correctness. They measure uptime, drift, and coverage. Product teams are optimised for adoption and value delivery. They measure activation rates, retention, and time-to-value.

An internal developer platform is a product and its users are your engineers. If they are not using it willingly, it is failing, regardless of how technically sound the architecture is.

I have seen platform teams at tech companies spend 18 months building a deployment abstraction layer that reduces the platform team's own operational burden considerably, without measurably reducing the time engineers spend getting code to production. That is infrastructure work masquerading as platform work.

The Golden Path That Leads Nowhere

The concept of a "golden path" (aka "paved path") is sound: provide an opinionated, well-maintained route for common tasks so engineers do not reinvent the wheel. The problem is what happens after launch.

Golden paths require active maintenance. The moment your cloud provider changes an API, your security baseline shifts, or a new compliance requirement lands, the golden path either gets updated or it becomes a liability.

Most platform teams do not staff for maintenance. They staff for build. So 12 months after launch, the golden path to "deploy a new microservice" is three major Kubernetes versions out of date, references a deprecated IAM pattern, and takes 40 minutes to run because nobody optimised the CI pipeline.

Engineers notice. They quietly fork the template and they build their own thing. Over time the platform becomes optional in practice, even if it is mandatory on paper.

I have seen a major tech companies IDP have a stated adoption rate of over 85% just because 85% of services were registered in the service catalogue. Active weekly usage of the self-service tooling was hovering around ~12%.

Registration is not adoption.

What Actually Works

The platform teams that get this right share a few behaviours:

• They treat engineers as customers and do user research: quarterly surveys, office hours and watching engineers use the tooling live.
• They publish an adoption dashboard internally. Active users, time-to-first-deploy and support ticket volume. Transparent, visible and reviewed in every sprint.
• They maintain a changelog and communicate deprecations like an external API. Engineers stop trusting platforms that change without warning.
• They staff a rotation for maintenance. At least one engineer per sprint is explicitly working on keeping existing paths current, not building new ones.
• They say no to features that do not improve adoption metrics. Platform teams are not concierge services.

The staffing ratio that tends to work in practice: one platform engineer per 8-10 product engineers, with at least 30% of their time ring-fenced for maintenance and support. Below that ratio you end up building more than you can sustain.

Mandate Is a Symptom of Poor Product-Market Fit

When a platform team starts lobbying for mandates, it is a signal that means the platform is not earning adoption through value. Mandating usage buys compliance, not trust. Engineers will do the minimum required to satisfy the policy and work around the platform everywhere they can.

The better question: if you removed the mandate, would engineers still use this? If the answer is no, you have a product problem, not a compliance problem.

This does not mean mandates are never appropriate. Security guardrails and compliance baselines sometimes need enforcement. But if you are mandating your deployment pipeline because engineers find it slower than doing it manually, you have built a worse tool and then punished engineers for noticing.

If you are building or scaling a platform team, start with adoption as your north star metric. Everything else follows.

Is your platform team measuring the right things, or are you counting registrations and calling it adoption? I would be interested to hear how your organisation thinks about this.

If you are trying to get more out of your platform investment or are deciding whether to build one at all, book a strategy call and we can work through it.