Stop building a platform nobody asked for: the internal developer platform trap

The pattern is so common it has become a joke in platform engineering circles: a team gets a Kubernetes cluster, writes a Helm chart, builds a CI/CD pipeline, and then decides to build an internal developer platform. Six months later, they have a Backstage instance with three plugins, a documentation site that nobody reads, and a set of golden paths that only the platform team understands.

The developers are still deploying the way they always did. The platform sits there, impressive in the architecture diagram, unused in practice.

The platform that was never asked for

I reviewed an internal developer platform for a fintech in Dubai last month. The platform team had spent eight months building it. They had a beautiful Backstage portal, custom scaffolder templates, a service catalog with 40 services registered, and a deployment pipeline that could ship a new microservice in twelve minutes from template to production.

The developers had never used it.

When I asked the developers why, the answers were variations of the same thing: “I do not understand the templates,” “the pipeline does not support our language,” “the documentation is written for the platform team, not for us,” and the most honest one: “it is faster for me to just deploy the way I always have.”

The platform team had built a platform for themselves. They built what they thought developers wanted, based on what the platform team would have wanted if they were developers. They never asked.

The three signs you are building the wrong platform

Sign one: developers are not in the room

If your platform planning meetings do not include at least two application developers who are not on the platform team, you are building for yourself. Period. The most common failure mode in platform engineering is a platform team that designs in isolation and then wonders why adoption is zero.

The fix is simple: invite developers to the planning meetings. Not as stakeholders who get a demo at the end. As participants who shape the roadmap from day one.

Sign two: the golden path is paved with assumptions

A golden path is supposed to be the easiest way to do something. But many platform teams build a golden path that is the easiest path according to the platform team’s values: fully automated, fully templated, fully opinionated. If a developer’s actual workflow does not fit the template, the golden path becomes a wall.

I saw this at a company in Amsterdam. The platform team built a golden path for Java services with Spring Boot, Gradle, and a specific Helm chart structure. 60% of their services were Python. The golden path did not support Python. The developers who wrote Python kept deploying with their own pipeline, and the platform team kept adding features to a golden path that served less than half the engineering org.

The fix: before you build a golden path, catalogue what your developers actually ship. Languages, frameworks, deployment patterns, environments. Build the path for the majority, not for the architecture diagram.

Sign three: you measure adoption, not satisfaction

If your platform KPIs are “number of services onboarded” and “percentage of deployments through the platform,” you are measuring the wrong thing. A developer who was forced to onboard their service to keep their manager happy is not an adopter. They are a hostage.

The metrics that matter:

• How long does it take a new developer to ship their first service? This is the real golden path test.
• Do developers choose the platform when they have an alternative? If there is a shadow pipeline, that is not rebellion, that is feedback.
• When you ask developers “does the platform make your job easier?” do they say yes without hedging? If the answer is “yes, but…” the “but” is the problem.

What a good platform actually looks like

I have seen one internal developer platform that worked. It was at a company in Tallinn, forty engineers, no dedicated platform team. The platform was not Backstage. It was not a portal. It was three things:

1. A single Makefile target that every service had: make deploy. It handled building, tagging, pushing, and deploying. It worked for every language because the team had written per-language wrappers. A new developer could deploy in their first hour.

2. A set of three Helm charts: simple, standard, and stateful. You picked one, filled in a values.yaml that had twelve lines, and you were done. No chart-of-charts, no library dependencies, no sub-chart inheritance. Twelve lines.

3. A runbook that lived next to the code, not in a wiki. Each service had a RUNBOOK.md in its repository that was rendered in the CI pipeline output when a deployment failed. If the deployment broke, the runbook was right there.

That is a platform. It was not fancy. It did not have a name. It did not have a launch. But every developer used it, because it was easier than not using it.

The question that saves you six months

Before you build an internal developer platform, ask one question to five developers on your team: “What is the most annoying part of shipping code right now?”

If they all say the same thing, build a solution for that. Not for the next five things. For that one thing. Ship it. Then ask the question again.

If they all say different things, you do not have a platform problem. You have an inconsistency problem. Fix the inconsistency first, then build the platform on top of consistency.

If they say “nothing is annoying, shipping is fine,” you do not need a platform. Go work on something else. Not every team needs one. The teams that do need one know they need one because their developers are complaining.

The trap is not ambition, it is isolation

Building an internal developer platform is not wrong. The ambition is not the problem. The problem is building it in isolation, for an audience you have not talked to, against problems you have assumed.

The best platforms I have seen were built incrementally, with developers in the room, solving one annoyance at a time. The worst platforms I have seen were built in six months of secrecy, unveiled at a company all-hands, and quietly abandoned within a year.

The difference is not engineering quality. It is whether you talked to the people you were building for.