Is DIY platform engineering actually dead? We spent 8 months on Backstage before switching to managed

General
1

I’m writing this from a place of hard-earned humility. Eight months ago, I made what felt like the right decision: build our internal developer platform on Backstage. I’m now convinced we made the wrong call, and I want to share why.

The Decision

In early 2025, we were scaling from 50 to 120 engineers. Self-service infrastructure became critical. Backstage seemed perfect—open source, extensible, backed by Spotify’s credibility. The build-vs-buy analysis looked clear: why pay for a managed solution when we have the engineering talent?

We assigned two senior engineers full-time. Smart, capable people who’d built complex systems before.

The Reality

Eight months later:

  • 10% developer adoption despite extensive documentation and training sessions
  • Two senior engineers producing zero product value for our customers
  • Growing plugin debt as the Backstage ecosystem evolved faster than we could keep up
  • Increasing maintenance burden for security patches, API updates, and integration breakages

The breaking point came when I calculated the opportunity cost. Two engineers at K fully-loaded × 8 months = K spent. Adoption was stuck. The engineers were frustrated. Our actual differentiating platform features—custom deployment pipelines, observability integration, incident response workflows—weren’t getting built.

The Switch

We evaluated Roadie, Port, and Cortex. We chose Roadie because it gave us Backstage’s ecosystem compatibility without the operational overhead. The migration took three weeks instead of the six months we’d already burned.

Three Months Later

Current state:

  • 60%+ developer adoption with Roadie’s onboarding and UX improvements
  • Two freed senior engineers now building features that actually differentiate our developer experience
  • Faster plugin updates and security patches handled by the Roadie team
  • Better support than we could provide ourselves

The hard truth: maintaining commodity infrastructure isn’t a competitive advantage. The teams achieving the best outcomes buy or use managed solutions for the interface layer, freeing platform engineers to focus on unique Golden Paths and integrations.

The Question

I’m curious where the community stands on this. Is DIY platform engineering actually dead in 2026?

Are there still scenarios where building from scratch makes sense? Company size? Industry constraints? Regulatory requirements?

Or have we reached the maturity point where platform engineering is like running your own email servers—technically possible, strategically questionable?

I’d especially value perspectives from those who:

  • Successfully scaled DIY platforms beyond 20% adoption
  • Work in regulated industries where SaaS isn’t an option
  • Made the opposite choice (managed → self-hosted) and don’t regret it

What am I missing?

2

Michelle, I appreciate you sharing this so openly. The numbers are compelling, and I don’t doubt the value you’re seeing with Roadie. But I want to challenge the premise that DIY is universally dead—particularly for those of us in heavily regulated industries.

The Compliance Reality

I lead engineering at a Fortune 500 financial services company. We evaluated the exact same options: self-hosted Backstage, Port, Roadie, Cortex. The decision matrix looked very different for us.

Our constraints:

  • Data residency requirements that prohibit customer data from touching third-party SaaS
  • SOC 2 Type II audit trails that require us to control every access log and change record
  • Regulatory examinations where we need to demonstrate complete ownership of developer tooling
  • Air-gapped environments for certain workloads that simply can’t call external APIs

Managed solutions like Roadie are architecturally incompatible with these requirements. Port and Cortex offer on-prem deployments, but the licensing costs for our scale (200+ engineers) would exceed the fully-loaded cost of our platform team.

Our DIY Journey

We’ve had a platform team running self-hosted Backstage for 18 months. The experience hasn’t been pain-free, but it’s also not the disaster scenario you described:

  • 35% adoption after 12 months (slower than I’d like, but growing)
  • Four dedicated platform engineers (yes, significant investment)
  • Quarterly plugin updates rather than chasing every release
  • Internal service catalog covering 180+ services

The operational burden is real. Security patches, plugin maintenance, API versioning—it all takes time. But we view this as necessary infrastructure cost, like running our own identity management or secrets management systems.

The Question for Regulated Industries

Here’s what I’m genuinely curious about: What should companies in regulated industries do when SaaS simply isn’t an option?

The choice isn’t DIY vs managed—it’s DIY vs nothing. And nothing means developers spinning up infrastructure without guardrails, which creates far bigger compliance and security risks.

I agree that maintaining commodity infrastructure isn’t a competitive advantage. But in financial services, demonstrating control over developer tooling is a regulatory requirement, not a strategic choice.

Maybe the real question is: at what company size and regulatory complexity does the DIY tax become justified?

For startups and mid-stage SaaS companies without compliance constraints, your path makes total sense. For banks, insurance companies, healthcare providers—I’m not sure we have better options yet.

3

Michelle, your 10% → 60% adoption jump tells the whole story. That’s not a marginal improvement—that’s the difference between platform failure and platform success.

Luis raises fair points about regulatory constraints, but for the 90% of companies that don’t operate air-gapped financial infrastructure, I think the strategic clarity is even sharper than you described.

The Core Strategic Question

We’re in the middle of this exact evaluation right now at my edtech company. Port vs Roadie vs Cortex. What crystallized the decision for me was asking: What Golden Paths actually differentiate our developer experience?

The answer wasn’t “better UI for the service catalog” or “smoother plugin updates.” Those are commodity features now. The differentiation comes from:

  • Education-specific compliance workflows (FERPA, COPPA, state-level student data privacy)
  • Custom deployment patterns for multi-tenant school districts
  • Incident response automation tailored to school calendars and outage windows
  • Observability integrations that surface student impact metrics

None of those require us to maintain the platform interface itself. They’re integrations and Golden Paths that sit on top of a stable platform foundation.

The Hidden Cost You Mentioned

This line hit hard: “Two senior engineers producing zero product value for our customers.”

I just looked at our org chart. If we dedicated two senior engineers to DIY Backstage:

  • Q1-Q3 2026: Building basic service catalog, maintaining it, fighting adoption
  • Lost opportunity: FERPA compliance automation that would reduce manual review from 3 days to 3 hours

That compliance automation directly impacts our product velocity. It reduces risk. It creates competitive advantage.

The platform UI? That’s table stakes. Necessary but not sufficient.

Teams That Recognize This Win

Your observation about teams achieving the best outcomes is exactly what I’m seeing in the market. The high-performing platform teams buy or use managed solutions for the interface layer, then focus entirely on unique integrations that reflect their business domain.

The teams stuck at 10% adoption are the ones building everything from scratch, treating platform engineering like it’s 2018.

One Metric That Matters

You mentioned your two freed engineers. What’s their velocity now on actual differentiating features compared to when they were maintaining Backstage?

I’m building the business case for our leadership, and “platform team velocity on product work” is the metric I want to anchor to. Not “cost of managed solution” but “opportunity cost of DIY maintenance hell.”

4

Okay, designer perspective incoming because that 10% adoption number is haunting me.

Michelle, I don’t think your problem was just “DIY platform engineering.” I think your problem was building infrastructure without product thinking.

The Adoption Crisis is a UX Crisis

10% adoption after 8 months with “extensive documentation and training sessions” screams a few things to me:

  1. No user research - Did anyone actually talk to the developers about what they needed? Or did the platform team build what they thought developers should want?

  2. No onboarding flow - Documentation ≠ onboarding. Commercial products invest heavily in first-run experiences, progressive disclosure, contextual help. DIY platforms often dump a wiki link and hope for the best.

  3. No feedback loops - How did you measure developer sentiment? Did developers even know who to complain to when things broke?

  4. No design system - Was the UI consistent? Accessible? Or did it feel like an internal tool that no one wanted to touch?

This isn’t unique to your team. I’ve seen this pattern everywhere: engineers build platforms for engineers, but forget that developers are users too.

Why Roadie Hit 60% Adoption

It’s not just because they handle security patches. It’s because they have:

  • Customer success teams who onboard users and gather feedback
  • UX designers who actually think about developer journeys
  • Product managers who prioritize features based on user research
  • Design systems that make the interface feel cohesive and professional

These aren’t “nice-to-haves.” These are core competencies for any product that needs adoption.

The Question No One Asked

Did your internal platform team ever sit with developer-users and watch them try to use the platform? Did you run usability tests? Did you have a feedback mechanism beyond Slack complaints?

Because Roadie does. Every commercial platform does. That’s literally their job.

DIY platforms often lack product discipline. You built infrastructure, not a product. And developers voted with their feet—90% of them walked away.

Maybe It’s Not DIY That’s Dead

Maybe what’s dead is treating platform engineering like an infrastructure project instead of a product.

If you had dedicated a product designer and a PM to your DIY effort alongside those two engineers—would you have hit 60% adoption? Maybe.

But at that point, you’re not just running DIY Backstage. You’re running a full product org for an internal tool. And for most companies, that resource allocation doesn’t make sense compared to buying a product that already has all that expertise baked in.

5

This is a classic build-vs-buy case study, and Michelle’s numbers tell the story perfectly. Let me break down the product strategy lens on this.

The Build-vs-Buy Framework

The decision comes down to three questions:

  1. Does this create a competitive moat? No. Platform interface is table stakes.
  2. Can we build it better/cheaper than buying? Rarely. Commercial vendors have product teams, designers, customer success—resources you’d need to replicate.
  3. What’s the opportunity cost? This is where Michelle’s story gets interesting.

The Real Calculation

Michelle mentioned: 2 engineers × 8 months × K fully-loaded = K spent

But that’s just the direct cost. The opportunity cost is what those engineers didn’t build:

  • Custom deployment pipelines
  • Observability integration
  • Incident response workflows

Let’s say those features would have generated K in avoided incidents, faster deployments, and reduced manual toil. The real cost of DIY isn’t K—it’s K (direct + opportunity).

Now compare that to Roadie’s pricing: ~K-100K/year for a mid-stage company. Even at the high end, you’d need 7+ years before self-hosting breaks even, and that assumes zero ongoing maintenance cost (which we know is false).

When Self-Hosting Makes Sense

Luis raised the regulated industry question, and it’s valid. But let’s be precise about when the math works:

Self-hosting justified when:

  • Regulatory requirements genuinely prohibit SaaS (rare, but real for financial services, defense, healthcare)
  • Company scale exceeds 500+ engineers where licensing costs > platform team costs
  • Unique technical constraints that no vendor supports (air-gapped, proprietary infrastructure)

Self-hosting NOT justified when:

  • You have engineering talent (doesn’t mean you should use it this way)
  • You want customization (vendors offer extensibility)
  • You’re worried about lock-in (switching costs exist either way)

Maya’s Point About Product Thinking

Maya nailed it. The 10% → 60% adoption jump isn’t just about maintenance burden. It’s about product discipline.

Roadie has:

  • Product managers who prioritize based on user feedback
  • Designers who optimize onboarding flows
  • Customer success teams who drive adoption

Replicating that internally means you’re not building a platform team—you’re building a product org for an internal tool. For most companies, that resource allocation is strategic malpractice.

The Broader Pattern

This mirrors every build-vs-buy decision in modern software:

  • Run your own email servers? No, use Google Workspace.
  • Build your own monitoring? No, use Datadog.
  • Create your own identity management? No, use Auth0.

The pattern: commodity infrastructure with high operational overhead moves to managed services, freeing engineering resources for differentiated product work.

Platform engineering just hit that maturity point in 2026.

Question for Michelle

You mentioned Roadie pricing wasn’t a concern. At what monthly cost would you have reconsidered self-hosting? I’m trying to understand the threshold where the economics flip.