Platform Engineering Stalls at 10% Developer Adoption

An engineering team spends 18 months building an internal developer platform. They configure Backstage, wire up service catalogs, set up golden paths for deployments, and present the result at an all-hands. Six months later, 64% of their engineers are still deploying with raw kubectl commands, bypassing everything the platform team built.

This is not an edge case. It is the norm.

Gartner projects that 80% of large software engineering organizations will have dedicated platform engineering teams by the end of 2026. The platform engineering and IDP market is projected to grow from $10.44 billion to $31.57 billion by 2031. But behind these numbers lies an uncomfortable reality: average internal portal adoption sits at roughly 10%.

The problem is not that platform engineering does not work. It is that most teams treat it as an infrastructure project when it is actually a product problem.

Why Developers Bypass Your Portal

Developers are not opposed to platforms. They are opposed to friction. When a developer can deploy a service faster with a bash script than through your golden path, the golden path loses every time.

The research backs this up. Development teams use 7.4 tools on average, and 75% of developers report losing 6 to 15 hours per week to context switching between them. Adding another tool — even one designed to consolidate — creates a net-negative experience if it does not immediately reduce that switching cost.

Three patterns consistently kill adoption:

The catalog nobody trusts. Only 3% of engineers feel the data quality of their metadata repository is completely trustworthy. When service ownership data is stale or deployment statuses are wrong, developers learn to ignore the portal entirely. Trust is the foundation, and most platforms break it in the first month.

The golden path that is actually a detour. When paved paths require more steps than the manual alternative, developers walk around them. The best platform teams measure the time-to-first-deployment for new services against the old workflow. If it is not demonstrably faster, the platform has a product problem.

The portal that solves ops problems, not developer problems. Many platforms are built by operations-minded engineers who optimize for standardization and compliance. These are valid goals, but they are invisible to the developer whose daily pain is finding out which team owns an API or waiting two days and a Jira ticket to spin up a test environment.

The Backstage Paradox

Backstage holds roughly 89% market share among organizations that have adopted an internal developer portal. It has over 3,400 adopters worldwide and a massive plugin ecosystem. It is, by most metrics, the dominant tool in the space.

It is also where many platform engineering initiatives stall.

A production Backstage deployment takes weeks to get right. Upgrades are frequent and often include breaking changes. Plugin quality varies wildly. The ongoing maintenance — vetting plugins for security, managing the React frontend, keeping catalog data synchronized — consumes so much of the platform team's capacity that they never ship the features developers actually want.

Most teams that adopt Backstage are not Spotify. They do not have 300 dedicated platform engineers. They have a team of three to five people trying to build and maintain a custom portal from scratch while also supporting the infrastructure that runs production.

This is driving a market shift. Managed alternatives like Port, Cortex, and Roadie are gaining traction by handling the undifferentiated heavy lifting, letting platform teams focus on capabilities unique to their organization. The question is no longer whether to use Backstage but where your platform team should spend its limited capacity.

Run Your Platform Like a Product

The organizations that achieve high adoption rates share a common trait: they run their platform team like a product team, not an infrastructure team.

This means starting with user research. Not surveying developers about what features they want — that produces wish lists — but observing how developers actually work. Shadow an engineer through a deployment. Time how long it takes to spin up a staging environment. Count how many Slack messages get sent to find out who owns a service. At Sigma Junction, our approach to building software starts with understanding how people actually work, not how we assume they work. The same principle applies to internal platforms.

The highest-performing platform teams measure four things:

Time to first deploy. How quickly can a new engineer or a new service go from zero to running in production? If it takes more than a day, the platform is not yet solving the right problem.

Voluntary adoption rate. Are developers choosing to use the platform, or are they being mandated to? Mandated adoption masks underlying product problems. When adoption is voluntary and still high, the platform is delivering genuine value.

Support ticket volume. A well-designed platform reduces infrastructure-related support requests. If the platform team is drowning in tickets, the platform is adding complexity rather than removing it.

Cognitive load reduction. This is harder to measure but more important than the rest. Are developers spending less time thinking about infrastructure and more time writing application code? Team Topologies' cognitive load framework provides a useful lens here.

Five Patterns That Drive Real Adoption

Studying platform teams with adoption rates above 60% reveals consistent patterns.

Start narrow, not broad. The most successful platforms launch with one or two capabilities that solve a specific, painful problem. A self-service environment provisioning system that eliminates the two-day Jira ticket workflow will drive more adoption than a comprehensive portal that does everything adequately.

Ship with your developers, not to them. Embed a platform engineer in a product team for a sprint. Let them see the actual developer workflow, feel the friction points, and build solutions alongside the people who will use them. This mirrors how custom software development works for external clients — and it should be how internal platforms work too.

Make the right path the easy path. Do not block developers from using kubectl directly. Instead, make the platform's deployment flow so much faster and more reliable that kubectl feels like extra work. Paved paths work when they are downhill, not when they have guardrails on either side and a speed limit sign.

Invest in data quality obsessively. Automate catalog population from CI/CD pipelines, Git repositories, and cloud provider APIs. Never rely on developers manually updating service metadata. If the catalog is automatically accurate, developers will trust it. If it requires manual upkeep, it will rot within weeks.

Measure and communicate value. Publish internal dashboards showing how much time the platform saves. Share before-and-after metrics in engineering all-hands. Developers adopt tools they believe in, and belief comes from evidence, not mandates.

Building Platforms Developers Actually Choose

Platform engineering is not failing. The $10 billion market and 80% organizational adoption prove that the industry understands the problem. What is failing is the execution — the gap between building a platform and building a product that developers prefer over the alternatives.

The fix is not more features or better tooling. It is a shift in mindset. Platform teams that succeed treat developers as customers, not consumers. They measure adoption as a product metric, not a compliance metric. They ship small, iterate fast, and earn trust incrementally.

For organizations planning their platform engineering strategy, the path forward starts with identifying the single highest-friction workflow in your engineering organization. Build a platform capability that makes it effortless. Measure adoption. Iterate. Only expand scope when developers are pulling you toward more capabilities, not when a roadmap says it is time.

Whether you are starting a platform engineering initiative or struggling with adoption on an existing one, the principle is the same: build for the developer, not for the org chart. If your team is ready to shift from building infrastructure to building a product developers want to use, get in touch.