Platform Engineering DIY Is Dead: What Happens to Early Adopters Who Built Custom?

General
1

I’ve been following the platform engineering movement closely, and the narrative shifted hard in 2026. Gartner predicted 80% of large software orgs would have platform teams by end of year—but DORA’s latest report shows 89% of enterprises already have internal platforms. We hit the prediction a year early.

Then Roadie drops their hot take: “DIY IDPs die in 2026; managed solutions prevail.” As someone leading a 40+ engineer team at a Fortune 500 financial services company, this hits different. We’ve invested 2-3 years building our custom platform. Now the industry is declaring DIY dead.

The Early Adopter Dilemma

Here’s my situation, and I’m betting many of you are in similar boats:

What we built: Custom internal developer platform tailored to financial services compliance requirements. Service catalog, deployment pipelines, compliance gates, audit logging—all purpose-built for our regulatory environment.

The investment: Two dedicated platform engineers full-time for 18 months, plus contributions from 5-6 senior engineers. Easily $1M+ in fully-loaded costs.

The results: Mixed. About 40% developer adoption. Teams using it love it. Teams not using it… have found workarounds.

Now the data is sobering: Roadie reports DIY efforts stall at 10% adoption after 6-12 months of maintenance hell. Byteiota found 60-70% of platform teams fail within 18 months—root cause is treating this as a technical project instead of a product.

The Uncomfortable Questions

I’m facing questions from leadership I don’t have clean answers for:

  1. Is our custom platform a competitive advantage or technical debt? We shipped features competitors don’t have—but if 89% of orgs have platforms, is differentiation real?

  2. Do we migrate to Backstage (89% market share) or double-down on custom? Migration means abandoning years of work. Doubling-down means swimming against industry tide.

  3. Managed (Roadie/Port) vs self-hosted Backstage vs stay custom? Each path has different cost, control, and capability trade-offs.

  4. How do we justify continued investment in custom when industry is consolidating? CFO wants ROI proof. “We’re special” isn’t landing anymore.

What I’m Seeing in the Data

The consolidation is real:

  • Backstage: 89% market share among IDP adopters
  • Self-hosting Backstage: 6-12 months to value, often stalls at low adoption
  • Managed solutions: Faster time-to-value, less control
  • DIY custom platforms: High effort, mixed adoption, maintenance burden

But here’s the nuance: the 60-70% failure rate isn’t because DIY is inherently bad. It’s because teams build what they think developers need instead of what developers actually need. We’re infrastructure engineers building technical showcases, not product teams solving user pain.

Where I Need Your Help

For those of you who’ve been through this:

If you migrated from custom to Backstage/managed: What drove the decision? Any regrets? How did you handle the team impact (both platform engineers and the devs who used your custom platform)?

If you doubled-down on custom: How did you justify it? What changed to make it work? How do you compete with the Backstage ecosystem?

If you’re early in your platform journey: Are you even considering custom anymore, or is Backstage the default starting point in 2026?

The platform engineering movement is maturing fast. Those of us who were early adopters built custom because there weren’t great alternatives in 2022-2023. Now in 2026, the landscape is different. I’m trying to figure out whether our custom platform is a strategic asset worth defending or technical debt we need to migrate away from.

What would you do?

Sources: Roadie - Platform Engineering in 2026: Why DIY Is Dead, Platform Engineering Predictions 2026, Platform Engineering 80% Adoption: 70% Fail Within 18 Months

2

Luis, this resonates deeply. We went through this exact evaluation 8 months ago at my SaaS company, and I want to push back gently on the “DIY is dead” absolutism while acknowledging the kernel of truth.

The Nuance: Custom Can Be Defensible

Your 40% adoption rate is actually above the 10% failure threshold Roadie cites—that matters. The question isn’t “DIY vs managed” as a binary choice. It’s whether your custom platform enables workflows that are defensible business capabilities.

Here’s the framework we used:

Custom makes sense when:

  1. Your platform encodes competitive differentiation (regulatory workflows, unique deployment patterns)
  2. Off-the-shelf solutions can’t handle your constraints (compliance, security, legacy integration)
  3. You’ve achieved >30% adoption and teams are pulling not being pushed
  4. Platform team treats it as a product with users, not infrastructure

Migrate to Backstage/managed when:

  1. Your platform is 80%+ commodity capabilities (service catalogs, docs, deployment dashboards)
  2. Adoption is stalled and you’re not sure why
  3. Maintenance burden exceeds new feature delivery
  4. You can’t hire/retain platform expertise

What We Did: Hybrid Approach

We migrated to Backstage as the base layer—got the 89% market share benefits (plugins, integrations, talent pool). But we kept our custom compliance workflows as Backstage plugins.

The migration:

  • 3 months to POC with managed Backstage (Roadie)
  • 2 months building custom plugins for our regulated workflows
  • 4 months migrating teams and deprecating old platform

The results:

  • Adoption jumped from 35% to 72% in 6 months
  • Platform team shifted from 60% maintenance to 80% new capabilities
  • But: we lost some deep customization, had to adapt workflows to Backstage patterns

Your Financial Services Context

Your compliance gates and audit logging are exactly the kind of defensible custom capabilities worth preserving. But do they need to live in a fully custom platform, or can they be Backstage plugins?

The question I’d push you to answer: Does your platform enable business capabilities competitors can’t replicate? If yes, you have a strategic asset. If it’s just a prettier UI on standard DevOps tools, that’s technical debt.

Your 40% adoption and financial services context suggest hybrid is the play. You have real domain-specific value—don’t throw that away. But you probably don’t need to own the portal, plugin system, and integration layer.

What does your platform do that Backstage + custom plugins couldn’t?

3

I’m going to challenge the premise that “DIY is dead” from a different angle—as someone who’s watched internal tools fail spectacularly.

The Real Problem: We Build Tech Projects, Not Products

That 60-70% failure rate Luis mentioned? The root cause isn’t DIY vs managed. It’s that platform teams are staffed with infrastructure engineers who think they know what developers need without actually asking.

I’ve seen this pattern at three companies:

Failed Internal Tool (Previous Company):

  • Built by infra team over 18 months
  • Technically impressive: microservices, GraphQL API, React frontend
  • Zero user research with developers
  • 8% adoption after launch
  • Team spent 2 more years adding features nobody requested
  • Eventually deprecated

Successful Design System (Current Company):

  • Treated as a product with users (product teams)
  • Monthly user interviews, quarterly surveys
  • Public roadmap with voting
  • Slack channel for support and feedback
  • 78% adoption in 12 months
  • Team focuses on adoption metrics, not technical perfection

Platform-as-Product Checklist

If you’re doing these things, DIY can succeed:

:white_check_mark: User research with developers (not assumptions)
:white_check_mark: Adoption metrics over technical metrics (% of teams using it vs response time SLAs)
:white_check_mark: Product roadmap based on user pain (not tech team interests)
:white_check_mark: Usability testing before shipping (watch developers use it)
:white_check_mark: Support channels and feedback loops (treat devs like customers)
:white_check_mark: Ruthless prioritization (ship what matters, cut what doesn’t)

If you’re NOT doing these things, Backstage won’t save you. You’ll just have a poorly adopted Backstage instance instead of a poorly adopted custom platform.

The Design Lens

Here’s what bothers me about the “just use Backstage” advice: Backstage is a framework, not a product. It’s like saying “just use React” when someone asks how to build a web app. You still have to:

  • Understand your users
  • Design workflows
  • Make opinionated choices
  • Test usability
  • Drive adoption

Backstage gives you components, not solutions.

Question for Luis: Have you done user research with the 60% of developers NOT using your platform? What are they doing instead? That’s where the product insights live.

The “DIY is dead” narrative lets platform teams off the hook for product thinking. The issue isn’t build vs buy—it’s whether you’re solving real user problems.

4

Luis, I lived this exact decision 9 months ago when I joined my current EdTech startup as VP Engineering. We had a custom platform that consumed 40% of our platform team’s time on maintenance. I want to share what drove our decision to migrate to managed Backstage.

The Team Impact Analysis

Everyone focuses on features and adoption, but the human cost of DIY platforms is underestimated:

Before migration (custom platform):

  • 2 platform engineers spending 60% time on maintenance
  • Remaining 40% on new features (always playing catch-up)
  • On-call rotation for platform issues (burned out team)
  • Hard to hire: “come maintain our custom Ruby platform” doesn’t attract talent
  • Knowledge concentrated in 2 people (massive key person risk)

After migration (managed Backstage via Roadie):

  • Same 2 engineers, but 80% time on custom plugins and workflow automation
  • Roadie handles: upgrades, security patches, base platform stability
  • No more platform on-call
  • Hiring pitch: “build Backstage plugins” attracts better candidates
  • Knowledge distributed: Backstage docs and community help onboard

The Trade-off We Accepted

What we lost:

  • Deep customization of core platform (had to adapt to Backstage patterns)
  • Full control over upgrade timing (Roadie handles it)
  • Some unique UI/UX touches we’d built
  • Platform expertise as team differentiator

What we gained:

  • Plugin ecosystem (300+ community plugins we didn’t have to build)
  • Talent market (easier to hire Backstage experience)
  • Vendor responsibility for base platform (Roadie’s SLA problem now)
  • Team focus on differentiation (our EdTech-specific workflows)

The Financial Services Lens

Your 40% adoption is actually solid—that’s above median. But I’d ask: What’s the opportunity cost of maintaining custom vs building on Backstage?

Run this calculation:

  • 2 FTE platform engineers @ $200K fully-loaded = $400K/year
  • If 60% goes to maintenance = $240K/year just keeping lights on
  • Managed Backstage: ~$50K-100K/year subscription
  • Savings: $140K-190K/year redirected to custom financial services workflows

Your compliance gates, audit logging, regulatory reporting—those are exactly the custom plugins worth building on top of Backstage. But the portal itself, the plugin system, the integration framework? That’s commodity.

The Question That Decided It For Us

Our CTO asked: “In 3 years, do we want to be known for our custom platform or for the EdTech workflows we enabled?”

We want to be the company with the best EdTech deployment patterns, compliance automation, and educator-focused tooling. Not the company with a custom platform.

What does your leadership team want to be known for in financial services?