Building platforms that developers actually want to use

Platform engineering is the new DevOps, but many organizations are making the exact same mistakes they made ten years ago. They are building massive, convoluted Internal Developer Platforms (IDPs) that force product engineers into rigid workflows, and then treating low adoption as a training problem instead of what it actually is: a product-market fit problem.

We saw this clearly with a client whose platform team had built what was, by any technical measure, an impressive internal platform: a Backstage-based developer portal, a custom Kubernetes operator for self-service environment provisioning, and a golden-path CI/CD pipeline with security scanning built in. Eighteen months in, adoption was under 20% of engineering teams. Everyone else was still hand-rolling their own Terraform and GitHub Actions workflows, which was exactly the fragmentation the platform was supposed to eliminate.

We spent the first two weeks not building anything, just doing what amounts to user research: shadowing engineers trying to ship a feature, timing how long each step took, and asking the teams who'd opted out why. The pattern was consistent. The platform's 'golden path' required a YAML manifest with 40+ required fields to provision a new service, most of which had a sensible default the platform could have inferred but didn't. A team that already knew Terraform could get the same result in a 15-line module they understood completely, versus a 40-field form whose defaults were opaque and whose failure modes produced Kubernetes-operator error messages, not application-level ones.

That's the core failure mode: the platform had been built to the platform team's mental model of correctness (comprehensive, explicit, no implicit defaults), not to the actual cognitive load budget of a product engineer who just wants to ship a feature and doesn't want to become a platform expert to do it. A mandatory system with a worse experience than the workaround doesn't get adopted. It gets routed around, no matter how technically sound it is.

The rebuild focused on exactly one metric: time and cognitive steps from 'I need a new service' to 'it's running and I can see logs,' compared directly against the DIY path teams were already using. We cut the required manifest from 40 fields to 6, with sensible, overridable defaults inferred from the repository structure for everything else. We replaced Kubernetes-operator error messages with a translation layer that surfaced application-level errors first. And critically, we made the platform opt-in with a hard floor: teams could bypass it entirely if they had the expertise to self-support, but bypassing it meant taking on the on-call burden for their own infrastructure choices. The platform's value had to be earned by being genuinely easier, not enforced by being mandatory.

We also instrumented adoption the way a product team instruments a feature: which steps in the provisioning flow had the highest drop-off, which error messages correlated with a team abandoning the platform for that service, and which teams were repeat users versus one-and-done. That data is what let us prioritize the manifest simplification over other technically interesting but lower-impact platform features the team had queued up.

Adoption crossed 75% within two quarters of the relaunch, without a single mandate email. The teams that stayed on custom Terraform were, almost without exception, teams with genuinely unusual infrastructure needs the golden path wasn't designed for, which is the correct outcome. A platform doesn't need 100% adoption to succeed; it needs to be the easiest path for the common case and get out of the way for the exception.

The generalizable lesson: an IDP is a product with internal customers who can and will churn to a worse-but-more-familiar alternative if the platform adds friction instead of removing it. Measure adoption and time-to-value the way a product team would, treat every mandatory field as a tax that needs to justify itself, and build the escape hatch for teams who genuinely don't need the golden path. A platform that has to be enforced by policy has already told you it hasn't earned voluntary adoption.