DIY Internal Developer Platforms Are Dead: 85% of Teams Will Adopt Commercial IDPs by 2026 — Did We Waste Two Years Building Backstage?

General
1

I need to have an honest conversation with this community about something that’s been eating at me for the past few months. As a CTO who bet heavily on the “build your own developer platform” movement, I’m starting to think we made a very expensive mistake.

The Prediction That Stung

Gartner’s latest research predicts that 85% of organizations with platform engineering initiatives will adopt commercial Internal Developer Platforms (IDPs) by the end of 2026. When I first read that number, my stomach dropped — because we’re one of the 15% still running a custom-built Backstage instance, and I can tell you exactly why that number is going to be right.

How We Got Here

Let me rewind. In late 2022, platform engineering was the hottest trend in DevOps. Every conference talk, every blog post, every vendor pitch was about building internal developer platforms. The narrative was compelling: your developers are drowning in cognitive load, your infrastructure is too complex, and the solution is to build a golden path — a self-service platform that abstracts away the complexity.

Backstage, Spotify’s open-source developer portal, was the darling of this movement. It had the pedigree (Spotify!), the ecosystem (plugins!), and the promise (extensibility!). So we went all in. I allocated 4 full-time engineers to build our IDP on Backstage. We spent 14 months designing service catalogs, building custom plugins, integrating with our CI/CD pipelines, and creating self-service templates for new services.

The Reality Check

Here’s the part that hurts to admit: after all that investment, only 30% of our developers actively use the platform. The rest either don’t know it exists, find it easier to use the tools directly, or have worked around it entirely.

The reasons for failure were predictable in hindsight:

Maintenance burden was crushing. Every Backstage upgrade broke something. Every new plugin needed custom integration work. Our 4-person platform team spent 60% of their time on maintenance and only 40% on new features. We effectively built a product that needed a product team, but we treated it like an infrastructure project.

We had no product management. Nobody did user research. Nobody tracked adoption metrics until month 10. Nobody ran feedback sessions with developers. We built what we thought developers needed based on what we read on Hacker News, not what they actually needed.

Feature creep was relentless. Every team wanted their specific workflow supported. The platform became a dumpling of every team’s pet integration rather than a focused tool that did a few things well.

Developers saw us as a bottleneck. Instead of empowering self-service, the platform team became a ticket queue. Need a new service template? File a ticket. Need a plugin updated? File a ticket. We recreated the exact problem we were trying to solve.

The Commercial Alternative

Meanwhile, companies like Humanitec, Cortex, OpsLevel, and Port have been quietly building commercial IDPs that solve 80% of the problem out of the box. They have dedicated product teams, established UX patterns, maintained plugin ecosystems, and — critically — they handle the upgrade path.

I spent the last two months evaluating three commercial IDPs, and I was humbled by how much ground they’ve covered. Features that took us months to build were available as configuration toggles. Integrations we never got around to were pre-built. The developer experience was, frankly, better than what we built.

The Decision

I’m migrating our team off our custom Backstage instance and onto a commercial IDP. The sunk cost of 14 months and 4 FTEs hurts — that’s roughly $1.2M in fully loaded engineering cost — but the ongoing maintenance cost hurts more. Those 4 engineers can now work on our actual product instead of maintaining internal tooling that most developers ignore.

The Deeper Lesson

Here’s what I wish someone had told me two years ago: platform engineering is a product discipline, not an infrastructure project. If you don’t have a dedicated product manager, a user research practice, adoption metrics, and a roadmap driven by developer feedback — you’re not building a platform. You’re building a science project.

The 85% prediction isn’t just about commercial tools being better. It’s about the industry recognizing that most engineering organizations aren’t equipped to run an internal product team. And that’s okay. Not every company needs to be a platform company.

I’d love to hear from others who’ve been through this journey. Did your DIY IDP succeed? What made the difference? And for those evaluating commercial options — what are you looking at?

2

Michelle, I appreciate your honesty here, but I have to push back — respectfully — because I was one of the engineers who built our Backstage instance, and I think the diagnosis is wrong.

The Problem Wasn’t Backstage

You listed four reasons your IDP failed: maintenance burden, no product management, feature creep, and becoming a bottleneck. Notice something? Three out of four are organizational problems, not technology problems. Swapping Backstage for Cortex or Humanitec doesn’t fix any of them.

I’ve seen this pattern before at Google Cloud. Teams would blame the tool when the real issue was how they operated. We had internal platforms that ran beautifully — not because the technology was superior, but because they had:

  • A dedicated PM who treated the platform like a product with users, not an infrastructure project with “consumers”
  • Quarterly developer surveys and NPS tracking
  • A strict scope: the platform did 5 things well instead of trying to do 50 things poorly
  • An explicit adoption strategy with onboarding, documentation, and developer advocates

Your platform didn’t have any of that. Of course it failed. But a commercial IDP without those things will fail too — just more expensively.

Commercial IDPs Have Their Own Problems

I’ve evaluated Humanitec and Port for our current company. Here’s what nobody tells you:

Vendor lock-in is real. Your service catalog, workflow definitions, and integrations all live in their proprietary format. Migrating between commercial IDPs is arguably harder than migrating from Backstage.

Customization hits a wall. The “80% out of the box” claim is true, but the remaining 20% is where your competitive advantage lives. When you need custom integrations with your specific CI/CD pipeline, deployment tooling, or compliance workflow, you’re back to writing code — except now you’re writing it against someone else’s plugin API with worse documentation than Backstage’s.

Cost scales aggressively. At 150 engineers, you’re looking at $100K-$200K/year for a commercial IDP. That’s less than 4 FTEs, sure, but you’ll still need 1-2 platform engineers to manage the integration, plus the ongoing commercial relationship overhead.

The Real Lesson

I agree with your deeper point — platform engineering is a product discipline. But the conclusion should be “invest in product management for your platform,” not “buy a commercial tool.” If you bring the same engineering-driven, build-it-and-they-will-come mentality to a commercial IDP, you’ll be writing this same post in 12 months about how the commercial tool didn’t get adopted either.

The tool doesn’t matter. The organizational commitment to treating your developers as customers matters. That’s the conversation we should be having.

3

Great thread, Michelle and Alex. I want to add an enterprise perspective because the reality at scale is more nuanced than “DIY vs. commercial.”

We Evaluated Five Commercial IDPs. None Worked Out of the Box.

At our Fortune 500 financial services company, we went through a rigorous 3-month evaluation of commercial IDPs: Humanitec, Cortex, OpsLevel, Port, and one smaller player I won’t name. We had a clear scorecard covering developer experience, compliance integration, SSO/RBAC, audit logging, and cost at our scale (400+ engineers across 60 teams).

The results were sobering. None of them could handle our compliance requirements out of the box. In financial services, every deployment needs an auditable approval chain. Every service needs to be mapped to a risk classification. Every infrastructure change needs to tie back to a change management record in ServiceNow. The commercial IDPs all had some version of “we can integrate with that,” but when we dug in, it meant custom development work — the exact thing we were trying to avoid.

The Hybrid Approach

What we ended up with is a hybrid model that I think is more realistic for complex organizations:

Commercial IDP for the 80% case. We adopted a commercial platform for service catalog management, developer onboarding, environment provisioning, and basic CI/CD workflows. These are solved problems, and the commercial tool handles them well.

Custom integrations for the 20% that’s company-specific. Our compliance workflows, risk classification system, regulatory reporting, and audit trails are all custom-built integrations that sit on top of the commercial IDP. We have a 3-person platform team that maintains these integrations.

This is not the same as building a full DIY platform. The 3-person team focuses exclusively on the compliance and governance layer. They don’t build service catalogs, template engines, or plugin systems. That’s the commercial tool’s job. The total cost (commercial license + 3 FTEs) is roughly half of what a full DIY platform would cost, and we get better developer experience for the common cases.

My Advice: Map Your Complexity First

Before choosing DIY or commercial, do this exercise: list every workflow your developers need, then classify each as “industry standard” or “company-specific.” Industry standard workflows (service creation, environment management, CI/CD integration) should be handled by commercial tools. Company-specific workflows (your unique compliance requirements, your specific deployment topology, your custom integrations) will need custom work regardless.

The mistake Michelle describes — building everything from scratch — is one extreme. The mistake of assuming a commercial tool will handle everything is the other extreme. Most organizations, especially those in regulated industries, will land somewhere in the middle.

One more thing: don’t underestimate the integration tax. Even with a commercial IDP, you’ll spend 3-6 months on integration, configuration, and migration. Plan for it, staff for it, and don’t let your leadership team think “buying” means “done.”

4

Can I offer a perspective from the other side of the platform? As someone who consumes developer platforms rather than builds them, I have a confession: I don’t care if the platform is DIY or commercial. I care if it works.

The Best Platform I Ever Used

At my previous company, the “developer platform” was a collection of well-documented Makefiles, a few shell scripts, and a Notion wiki. That’s it. No Backstage, no commercial IDP, no service catalog with a fancy UI. Just:

  • make new-service to scaffold a new service with all the boilerplate
  • make deploy-staging and make deploy-prod for deployments
  • make run-local that actually worked every time because someone maintained it
  • A Notion page with a decision tree: “I want to do X” → “Run this command”

It was ugly. It had no dashboard. It couldn’t generate architecture diagrams. But every single developer used it every single day because it was simple, fast, and reliable. The person who maintained it spent maybe 20% of their time on it. Total cost: near zero.

The Worst Platform I Ever Used

At another company, we had a fully-built Backstage instance with a beautiful UI, a service catalog, environment management, and custom plugins for everything. On paper, it was impressive. In practice:

  • It took 8 seconds to load the service catalog page
  • The service data was frequently out of date because nobody maintained the YAML files
  • Creating a new service through the portal took 15 clicks and 3 minutes; doing it manually with cookiecutter took 30 seconds
  • Half the plugins were broken because the Backstage version was 6 months behind

So I did what every developer does when the platform is worse than the alternative: I ignored it. I kept my own bookmarks, my own scripts, my own shortcuts. And so did most of my teammates.

What Actually Matters

The DIY vs. commercial debate misses the point entirely. Platforms fail when they optimize for elegance over usefulness. The questions that matter are:

  1. Is it faster than the alternative? If your platform adds steps instead of removing them, developers will route around it. Every. Single. Time.

  2. Is the data accurate? A service catalog with stale data is worse than no service catalog. At least with no catalog, developers know they need to ask someone. With a stale catalog, they trust wrong information.

  3. Does someone own the developer experience? Not the architecture. Not the infrastructure. The experience. Someone who watches developers use the tool, notices the friction points, and fixes them — not in the next quarter’s roadmap, but this week.

I’ve seen $2M platforms that nobody used and $0 platforms that everyone loved. The difference was never the technology. It was whether the people building it actually watched developers try to use it and felt the pain when it didn’t work.

Michelle, Alex, Luis — you’re all right about different pieces of this. But from the developer’s seat, I just want something that makes my day easier, not something that makes an architecture diagram prettier.