We Built an Internal Developer Platform and Nobody Used It

A consulting story about a platform engineering initiative that checked every box on paper but collected dust in practice — and the uncomfortable reasons why.

The pitch was compelling. A mid-size fintech client with 60 engineers across eight teams was drowning in operational overhead. Every team had its own Terraform modules, its own CI pipelines, its own way of deploying to Kubernetes. A new microservice took two to three weeks just to get running in staging. The CTO wanted a platform team.

I was brought in to help design and roll out an internal developer platform. Golden paths, self-service infrastructure, the whole vision. We had executive buy-in, a dedicated team of four engineers, and a six-month timeline. On paper, this was the dream engagement.

Six months later we had a polished platform. A service catalog in Backstage. Templated pipelines. One-click environment provisioning. Automated DNS, TLS, observability wiring. The demo was gorgeous.

Almost nobody was using it.

The builders who wouldn't switch

When I started digging into adoption numbers three months after launch, the picture was grim. Of the eight product teams, two had migrated their services to the platform. One of those was the team sitting next to the platform engineers. The other six teams had poked around, filed a few issues, and gone back to their existing setups.

The feedback wasn't hostile. It was worse — it was polite indifference. "Looks great, we'll migrate when we have time." Translation: never.

I spent a week doing 1-on-1s with tech leads to understand what went wrong.

Three things we got wrong

We built for the architecture we wanted, not the one that existed. The platform assumed every service was a containerized, stateless microservice deployed via Helm charts. That described maybe 40% of the actual fleet. Two teams ran monoliths with custom deployment scripts. One team had a batch processing system that needed GPU nodes. Another had a legacy service still deploying via rsync-over-SSH (yes, in 2025). The platform had no story for any of them, so those teams had no reason to adopt it.

We never made migration easy. We'd built a great experience for new services. Spinning up a fresh service from a template was genuinely pleasant. But nobody was creating new services that quarter. The real work was migrating 30+ existing services, and that migration path was a 47-step Confluence doc that started with "First, restructure your Dockerfile." One tech lead told me, "I estimated the migration at three sprints of work. My team has two sprints of feature work already committed. Do the math."

We didn't solve a pain point the teams actually felt. Here's the uncomfortable one. The platform team had surveyed developers early on and asked what their biggest pain points were. The top answers were: slow CI builds, flaky tests, and confusing access permissions. The platform we built addressed none of those. Instead, we'd focused on infrastructure provisioning — which was genuinely a mess, but it was a mess that each team had already learned to live with. We were solving a problem that bothered the CTO's org chart more than the developers' daily work.

What we changed

After the awkward adoption review, we made three course corrections.

First, we killed the "big migration" plan. Instead of asking teams to move everything at once, we added platform support for their existing deployment patterns. Rsync team? Fine, we wrapped their flow in a standardized pipeline that at least gave us observability hooks. The monolith teams got a platform template that wasn't Helm-based. Meeting teams where they were felt like a compromise, but it got six services onto the platform in two weeks.

Second, we tackled CI speed. The platform team took over the shared CI runners, bumped them to larger instances, added aggressive caching for Docker layers and dependency resolution, and cut average build times from 14 minutes to 4. That single change generated more goodwill than six months of platform features.

Third, we started embedding a platform engineer with each product team for one-week rotations. Not to do the migration for them, but to pair on it. This accomplished something no documentation could: trust. Developers saw a real person who understood their codebase helping them move, not a Confluence page lecturing them about best practices.

The adoption curve nobody talks about

By month nine, we had 70% of services on the platform. Not because we'd built something perfect, but because we'd stopped treating adoption as a feature problem and started treating it as a people problem.

Month 1-6:  Built platform → 2 teams adopted (polite applause)
Month 6-7:  Listened to feedback → adjusted approach
Month 7-9:  Solved real pain points → 6 more teams adopted

The thing that surprised me most: the teams that adopted last weren't the most resistant. They were just the most pragmatic. They waited to see if the platform would survive its first real incident, if the platform team would fix bugs quickly, if this was a management fad or a real commitment. Once they saw other teams genuinely benefiting, they migrated on their own without being asked.

What I'd do differently

If I ran this engagement again, I'd spend the first month doing nothing but shadowing developers. Not interviewing them — watching them work. Surveys are terrible at surfacing real pain because developers are terrible at articulating friction they've normalized. Nobody puts "my deploy script is a mess but it works" on a survey. You only see it when you sit next to someone and watch them spend 20 minutes on something that should take two.

I'd also resist the urge to build a "complete" platform before shipping anything. We spent four months in heads-down development before any product team touched the thing. That's four months of assumptions hardening into architecture. Ship the thinnest slice that helps one team, learn from it, then expand.

Platform engineering is having its moment right now — Gartner predicts 80% of engineering orgs will have platform teams by 2028. But the hard part was never the technology. Backstage, Crossplane, ArgoCD — the tooling is genuinely good now. The hard part is building something your colleagues will actually choose to use when their existing setup, however ugly, already works.

How do you drive adoption of internal tools at your organization? I'm curious whether the "embed and pair" approach scales, or if it only worked because we had a small enough org to do it personally.