We Spent 18 Months Building Our Platform—Now Everyone Says DIY Is Dead

General
1

I need to be honest with y’all—I’m struggling with a massive sunk cost dilemma and I’d love your perspectives.

The Situation

When I joined my current company two years ago as VP of Engineering, one of my first big initiatives was building an internal developer platform. We’d grown from 25 to 60 engineers, and the pain was real: inconsistent deployment processes, knowledge silos, new engineers taking weeks to ship their first code.

We committed hard. A dedicated team of 5 engineers spent 18 months building a custom Backstage implementation with:

  • Custom service catalog integrations
  • Bespoke deployment workflows for our multi-tenant architecture
  • Homegrown templates for our specific tech stack
  • Internal plugins for our compliance requirements

The team did beautiful work. Our developers loved it. Onboarding time dropped from 3 weeks to 3 days. We were proud.

The Problem

Fast forward to today, and I’m reading that platform engineering DIY is dead. Gartner says 80% of software orgs will have platform teams by 2026, but the smart ones are buying managed solutions, not building from scratch.

Now I’m seeing it play out:

  • Our platform team is underwater maintaining what we built
  • Feature requests are piling up faster than we can address them
  • Every Backstage version upgrade is a multi-week project
  • The team that built this wants to work on product features, not platform infrastructure
  • Meanwhile, managed Backstage providers have shipped AI-powered workflows, better integrations, and features we’d need months to build

The Data That Haunts Me

According to the research, DIY platforms typically take 6-12 months just to get to basic functionality, with complex implementations running 18+ months. That was us.

But what I didn’t account for: the ongoing maintenance burden. Teams achieving the best outcomes are buying or using managed solutions for the infrastructure layer, freeing platform engineers to focus on the unique golden paths and integrations that actually differentiate their developer experience.

The Leadership Dilemma

How do I walk into a room with my CEO and CFO and say, “Remember that 18-month investment in our custom platform that we celebrated last quarter? Well, I think we should migrate to a paid solution and redeploy our platform team to product work.”

It feels like admitting failure. Like we wasted time and money. Like I made the wrong call.

But the opportunity cost is crushing me. Every week our platform team maintains DIY infrastructure is a week they’re not:

  • Building golden paths for our unique ML deployment needs
  • Creating integrations with our proprietary systems
  • Solving actual differentiated problems for our developers

What I’m Considering

The hybrid approach makes sense to me: buy the managed Backstage core, keep our custom integrations via APIs and plugins, focus our platform team on what makes us unique.

But I need to make the case. And honestly, I need to know: Am I overthinking this? Has anyone else navigated this transition? How did you frame it to leadership?

The worst part is knowing that if I were starting today, I’d 100% choose managed. But we’re not starting today—we’re 18 months and significant investment deep.

Would love your honest takes. Especially if you’ve been in a similar spot.

2

Keisha, this resonates so deeply. I’ve been in almost the exact same position, and here’s what I’ve learned: this isn’t about admitting failure—it’s about demonstrating strategic leadership.

Reframing the Narrative

When I faced a similar decision 18 months ago with our cloud migration strategy, I had to shift how I thought about sunk costs. The investment you made wasn’t wasted—it gave you:

  1. Deep learning about what your developers actually need
  2. Credibility with your engineering org (they know you understand platforms)
  3. Clarity on what’s commodity vs. differentiated
  4. Leverage to evaluate vendors (you know exactly what questions to ask)

That 18-month journey made you the right person to make this next decision. A less experienced leader might have chosen managed from day one without understanding the trade-offs. You built first, learned what matters, and now you’re optimizing.

The Opportunity Cost Frame

Here’s how I framed it to our board: “We’re not abandoning our platform investment—we’re multiplying its impact.”

Show the math:

  • Platform team: 5 engineers × $200K fully loaded = $1M/year
  • Current allocation: 70% maintenance, 30% new capabilities
  • Managed solution cost: ~$150K/year
  • New allocation: 10% maintenance, 90% differentiated capabilities

Net result: You’re spending $150K to buy back $700K worth of engineering capacity. That’s a 4.6x ROI before you even count the new capabilities.

What’s Actually Differentiated

This is the critical piece. Your custom work on:

  • ML deployment golden paths
  • Proprietary system integrations
  • Compliance-specific workflows

None of that goes away. In fact, it becomes MORE valuable when you’re not drowning in Backstage version upgrades.

The managed provider gives you the commodity layer (catalog, UI, basic workflows). Your team focuses on the 20% that’s unique to your business and delivers 80% of the value.

Addressing the Leadership Conversation

When you talk to your CEO and CFO, lead with business outcomes, not technology decisions:

Don’t say: “Our platform choice was wrong, we need to switch vendors.”

Do say: “Our platform investment taught us exactly where we need to focus. By partnering with a managed provider for the infrastructure, we can redeploy our platform team to solve our unique ML deployment challenges and accelerate product velocity. This increases our engineering capacity by 60% without adding headcount.”

Frame it as evolution, not pivot. You’re not throwing away 18 months—you’re building on what you learned to unlock the next level of impact.

The Timeline Reality

One more thing: the longer you wait, the harder this gets. Your platform team’s morale is already suffering. Every quarter you delay is another quarter of opportunity cost AND another quarter of technical debt in your custom implementation.

The right time to make this shift was probably 6 months ago. The second-best time is now.

You’ve got this, Keisha. This is what strategic leadership looks like—making hard decisions based on new information, not defending past decisions that no longer serve the business.

3

Keisha, I went through this exact transition at my previous company, and Michelle’s advice is spot-on. Let me share the tactical playbook that worked for us.

Our Migration Journey

We built a custom CI/CD platform in 2023-2024. Similar story: initially celebrated, then became a maintenance nightmare. Here’s how we made the transition:

Phase 1: Build the Case (2 months)

We ran a structured analysis:

  • Time tracking: Platform team logged hours for 4 weeks—71% went to maintenance, only 29% to new features
  • Developer surveys: Asked our 50+ engineers what platform features they actually needed vs. had
  • Vendor evaluation: Tested 3 managed solutions with a small pilot team
  • TCO model: 3-year cost comparison (build vs. buy including opportunity cost)

The data made the case itself. Our CFO actually said, “Why didn’t you bring this to me sooner?”

Phase 2: Hybrid Architecture (3 months)

We didn’t rip and replace. We ran parallel:

  • Stood up managed platform alongside existing
  • Migrated one team at a time (we had 6 product teams)
  • Kept our custom integrations via APIs
  • Deprecated old platform after 90% migration

Key learning: Don’t try to replicate everything 1:1. Some custom features we built turned out not to be used. The migration forced us to simplify.

Phase 3: Team Transition (ongoing)

This was actually the hardest part. Our platform engineers had pride of ownership. They built something real that people used. Moving to “just” maintain integrations felt like a demotion to some.

We addressed this by:

  • Reframing the mission: “We’re not platform maintainers, we’re developer experience architects”
  • New challenges: Gave them hard problems (ML deployment workflows, security automation) that actually required their skills
  • Recognition: Celebrated the migration as a success, not an abandonment

Three engineers from our original platform team are now tech leads on product teams. One stayed focused on DX and is thriving building custom golden paths.

Results After 12 Months

  • Platform team time: 60% reduction in operational burden
  • Feature delivery: 3x faster (we shipped in 2 months what used to take 6)
  • Developer satisfaction: NPS went from 42 to 68
  • Cost: Managed solution cost less than one platform engineer’s salary

Advice for Your Situation

  1. Start the evaluation now: Don’t wait for perfect timing. The evaluation itself will give you data to make the case.

  2. Bring your platform team into the decision: They’re not the problem—the maintenance burden is. Let them help evaluate solutions and design the hybrid architecture.

  3. Focus on what you’ll gain, not what you’ll lose: The conversation isn’t about abandoning your platform, it’s about unlocking your team’s potential.

  4. Set a deadline: We gave ourselves 6 months to complete migration. Deadlines prevent endless deliberation.

Happy to chat more details if helpful. You’re making the right call here—trust your instincts.

4

Oh wow, this hits close to home! I’m coming at this from the design systems world, but I’ve watched this exact pattern play out with our tooling.

The Design Systems Parallel

In 2019, every company was building their own design system from scratch. Component libraries, design tokens, documentation sites—all custom built. My previous company spent 14 months building an internal design system with a team of 4.

Then Figma happened. Then design system tools like Storybook matured. Then managed solutions like Zeroheight emerged.

By 2021, the smartest companies were using Figma + Storybook + a documentation platform, and building ONLY the parts that were unique to their brand and needs.

The companies still maintaining fully custom design systems? They’re drowning, just like you’re describing with your platform.

What Design Learned (That Applies Here)

1. Commodity infrastructure becomes commodity fast

The cataloging, versioning, documentation—that stuff becomes table stakes. Every vendor offers it. Your differentiation isn’t in HOW you catalog components, it’s in WHICH components you build and WHY.

Same with platforms: The service catalog UI isn’t your competitive advantage. Your ML deployment workflows are.

2. The “not invented here” trap is real

Some of our designers resisted using “off-the-shelf” tools because it felt like admitting we couldn’t build better ourselves. But that’s ego talking, not strategy.

The question isn’t “Can we build this?” It’s “Should we build this when we could be building something more valuable?”

3. Hybrid is the sweet spot

We use Figma (don’t build our own design tool), Storybook (don’t build our own component preview), but we built our own component API layer and accessibility testing framework because those are unique to our needs.

You’re describing the same hybrid approach: buy the platform infrastructure, build the golden paths.

The Emotional Piece

Here’s what I wish someone had told me during our transition: your team didn’t fail—they succeeded at teaching the organization what matters.

That 18-month build gave your company clarity. Now you know:

  • What developers actually use vs. what you thought they’d need
  • Where the maintenance burden lives
  • What’s truly custom vs. what’s commodity

You couldn’t have learned that by choosing managed from day one. The build phase was the research phase. Now you’re in the optimization phase.

My Advice

Focus the conversation on developer experience, not platform architecture.

Ask your CEO: “Do we want our best engineers maintaining infrastructure, or building features that serve customers?”

The answer will be obvious. And that’s your green light to evolve.

:blue_heart: Rooting for you on this. Change is hard, but you’re making the right call for the right reasons.

5

Coming at this from the product/business side, and I think you’re sitting on a really strong case—you just need to frame it in terms leadership will understand.

The Business Framing

Your CFO doesn’t think in terms of “platform success” or “technical decisions.” They think in terms of:

  • Capacity: How many engineers working on revenue-generating features?
  • Speed: How fast can we ship what customers are asking for?
  • Risk: What happens if key platform people leave?
  • ROI: What’s the return on every dollar we invest?

Let’s translate your situation into that language.

The Capacity Argument

Current state:

  • 5 platform engineers
  • 70% maintenance, 30% new capabilities
  • Effective capacity: 1.5 engineers on value-add work

Proposed state:

  • 5 platform engineers
  • 10% maintenance (managed provider handles the rest), 90% new capabilities
  • Effective capacity: 4.5 engineers on value-add work

Translation: “We’re buying back 3 full-time engineers worth of capacity without adding headcount. That’s $600K/year in engineering capacity for a $150K managed platform investment. 4x ROI in year one.”

The Speed Argument

Right now, your platform team is underwater. That means:

  • Product teams waiting weeks for new deployment capabilities
  • New engineers still taking days to onboard (could be hours with better tooling)
  • Platform upgrades blocking other initiatives

Translation: “Moving to managed infrastructure removes our platform as a bottleneck to product velocity. We estimate this accelerates product delivery by 20-30% based on current backlog.”

The Risk Argument

This is the one CFOs and CEOs really care about: What happens if your key platform people leave?

Custom-built platforms create:

  • Knowledge concentration risk: Few people understand the system
  • Recruiting challenges: Hard to hire for custom tech
  • Retention pressure: Platform work becomes less interesting over time

Translation: “Managed platforms reduce our bus factor and make it easier to hire and retain top engineering talent who want to work on product innovation, not infrastructure maintenance.”

The Pitch Deck

Here’s how I’d structure the conversation:

Slide 1: Current Platform Success

  • Show the wins: onboarding time, developer satisfaction, deployment frequency
  • “Our platform investment taught us what developers need”

Slide 2: The New Challenge

  • Maintenance burden data (70% of team time)
  • Opportunity cost (3 engineers NOT working on product)
  • Competitive pressure (vendors shipping AI features we can’t match)

Slide 3: The Evolution Strategy

  • Hybrid approach: Buy infrastructure, build differentiation
  • Capacity gain: 3 FTE worth of product work
  • Cost: $150K/year platform + migration effort

Slide 4: The Business Impact

  • Product velocity: 20-30% faster delivery
  • Engineering efficiency: 4x ROI on platform spend
  • Risk reduction: Lower bus factor, easier hiring

Slide 5: The Ask

  • Budget approval: $150K/year platform subscription
  • Timeline: 6-month migration
  • Success metrics: Platform team time allocation, product delivery velocity

The Key Message

Frame this as doubling down on what’s working, not abandoning what failed.

“Our platform investment succeeded—it proved developers need great internal tooling. Now we’re scaling that success by partnering with platform infrastructure experts, freeing our team to build what’s unique to our business.”

No one can argue with that narrative. You’re not saying the build was wrong—you’re saying it proved the concept, and now it’s time to scale.

Good luck with the conversation. Based on everything you’ve shared, this should be an easy yes from leadership.