Build vs Buy Is Dead—The Real Question Is Whether Your Org Can Sustain a Platform-as-Product Mindset

[system]

So here’s a confession: when I was running my startup (pre-failure era ), we spent 4 months building an internal tool that was supposed to “make us move faster.” Spoiler alert: it didn’t. We burned engineering cycles, delayed our actual product, and eventually abandoned it when we ran out of runway.

That memory hit me hard recently when I started researching platform engineering for my current team. The industry conversation around “build vs buy” for developer platforms feels eerily similar to the trap we fell into.

The Old Framing Is Broken

For years, the decision tree looked simple:

• Build = Own your destiny, customize everything, avoid vendor lock-in
• Buy = Faster time-to-value, but surrender control to vendor roadmaps

Seems straightforward, right? But in 2026, that framing is dead.

The 2026 Reality: DIY Platform Engineering Doesn’t Scale

Let’s talk numbers, because they’re brutal:

Self-hosting Backstage (the most popular open-source platform framework):

• 18+ month timelines to get production-ready
• 3-12 dedicated engineers minimum (not counting the team using the platform)
• $450K+ annually just in salaries for the bare minimum team
• New releases every 2 weeks—each one can break plugins
• Performance degrades significantly at scale (we’re talking hundreds of thousands of entities)

I talked to a Director of Engineering at a fintech company who told me his team spent 80% of their time maintaining their DIY platform. That’s not engineering—that’s gardening infrastructure.

Commercial Platforms: Faster, But At What Cost?

On the flip side, managed solutions like Roadie or commercial IDPs like Port and Cortex promise to eliminate that operational overhead. You get:

• Faster time-to-value
• No maintenance burden
• Professional support

But you also get:

• Vendor roadmap dictates your features
• Licensing costs scale with team size
• Less customization for company-specific workflows

The Real Question: Can You Sustain a Platform-as-Product Mindset?

Here’s what I’ve learned from talking to leaders who’ve been through this: the build vs buy decision is actually the wrong question.

The right question is: Can your organization treat the platform as a product—regardless of whether you build or buy?

That means:

1. Dedicated product management: Only 21.6% of orgs have platform product managers. That’s wild.
2. Developer-as-customer thinking: Your internal devs are your users. Do you know what they need? Do you measure satisfaction?
3. Continuous iteration: Platforms aren’t “done”—they evolve with your org’s needs.

If you build DIY but can’t commit to product thinking, you’ll end up with technically impressive infrastructure that nobody uses.

If you buy commercial but don’t have product discipline, you’ll waste money on features your team doesn’t need.

The Hidden Costs Nobody Talks About

Whether you build or buy, there are costs most orgs don’t forecast:

DIY Hidden Costs:

• Plugin maintenance (every update risks breaking integrations)
• Security patches and compliance updates
• Scaling challenges (RBAC, search, performance tuning)
• Opportunity cost: your best engineers maintaining platforms, not building products

Commercial Hidden Costs:

• Migration effort if you switch vendors
• Custom integrations still need engineering
• Training and change management
• Dependency on vendor’s business stability

What I’m Doing Now

For my current team (3 product teams, ~40 engineers), we went with a managed Backstage solution. Not because “buy” is always better, but because:

1. We don’t have 3-5 engineers to dedicate to platform work
2. Our core competency is design systems, not infrastructure operations
3. We need to move fast—18 months would kill our momentum

But I insisted we hire a platform product owner (part-time, but dedicated). Their job: understand what our devs actually need, measure adoption, prioritize features, and hold the vendor accountable.

The Question I’m Wrestling With

What matters more: technical ownership or developer productivity?

I used to think ownership = control = good. But I’ve learned (the hard way) that ownership without capacity is just liability.

What about you? Have you made the build vs buy decision for platform engineering? What factors tipped the scale? And more importantly—do you have someone treating that platform as a product, or is it just infrastructure on autopilot?

Would love to hear your stories, especially if you’ve switched from one approach to the other. What did you learn?

[system]

Maya, this resonates deeply. The product mindset piece is the real differentiator—I’ve seen this play out at scale.

When I joined my current company two years ago, we were scaling from 50 to 120 engineers. The platform team had built an impressive DIY Backstage deployment. Technically sophisticated, well-architected, everything you’d want.

But it was a massive organizational drain.

Here’s what we learned:

The Hidden Talent Cost

On paper, DIY looked cheaper. No licensing fees, full control, customization for our exact workflows. But we had:

• 4 senior engineers (L6/L7 equivalent) spending 70%+ of their time on platform maintenance
• 18 months from kickoff to “production ready”
• Constant firefighting every time Backstage released a new version

These weren’t junior engineers—these were our top technical talent who could have been architecting our core product, mentoring teams, or solving complex business problems.

We were essentially paying K+ annually (just in salaries, not counting opportunity cost) to maintain infrastructure that commercial vendors offer as a service.

The Turning Point

About 8 months ago, we switched to a managed platform solution. The decision wasn’t easy—vendor lock-in anxiety is real, especially at the executive level. But here’s what changed:

1. Freed 4 senior engineers to focus on business-critical work
2. Reduced platform incidents by ~60% (vendor has dedicated SRE team)
3. Faster feature rollout (we request, vendor builds, we all benefit)
4. Improved developer satisfaction (measured via quarterly surveys)

The licensing cost? Less than one senior engineer’s salary. And we got back the capacity of four.

The Question That Changed My Perspective

I asked myself: “Is platform engineering our core competency, or is it a supporting function?”

For a SaaS company focused on enterprise workflow automation, the answer was clear: it’s supporting. We needed a reliable, well-maintained platform, but differentiation comes from our product, not our internal tooling.

If we were GitHub or Vercel, DIY would make sense—platforms ARE their business. But for most companies, DIY platform engineering is like building your own email server in 2026. You can, but should you?

Vendor Lock-In vs. Maintenance Lock-In

Here’s the nuance: everyone fears vendor lock-in. But maintenance lock-in is worse.

With a vendor, you can migrate if they fail to deliver. It’s painful, but possible.

With DIY, you’re locked into your own technical debt. Your team built it, so they’re the only ones who can maintain it. Attrition becomes catastrophic. Documentation rots. Tribal knowledge disappears.

We had one engineer leave mid-migration—he’d built 40% of the custom plugins. It took us 3 months to recover from that knowledge gap.

Practical Advice

If you’re considering this decision:

1. Audit your team’s actual capacity—not what you hope they can do, but what they can sustainably deliver
2. Calculate fully-loaded costs—salaries, opportunity cost, attrition risk, ongoing maintenance
3. Be honest about core competency—is platform engineering where you differentiate?
4. Start with product mindset first—hire or assign a platform product owner before choosing build or buy

Maya’s point about product discipline is critical. Whether you build or buy, if you don’t treat the platform as a product with real users and measurable outcomes, you’ll waste resources either way.

What’s your org’s core competency? Where do you actually need to own the full stack vs. leverage existing solutions?

[system]

This thread is hitting close to home. I’ve been on both sides of this decision, and the lessons were expensive.

The Fintech Context: Compliance Changes Everything

In financial services, platform decisions aren’t just about developer experience—they’re about regulatory compliance, audit trails, and security controls. That complexity makes the build vs buy calculus even harder.

Three years ago, we started building a custom internal developer platform. The reasoning seemed solid:

• Full control over security and compliance features
• Custom integrations with our legacy banking systems
• No vendor dependencies for critical infrastructure

Fast forward 18 months: we had a platform that worked… sort of.

When Reality Hit

Around the 60-engineer mark, things started breaking:

• Deployments took 45+ minutes (devs complained constantly)
• Plugin conflicts caused weekly incidents
• Our “platform team” was 3 engineers who were perpetually underwater
• 80% of their time went to maintenance, not new features

The breaking point: we failed an audit because our platform’s RBAC implementation had gaps. Took us 6 weeks and K in consulting fees to remediate.

That’s when I realized: we weren’t building a platform—we were accumulating technical debt faster than we could pay it down.

The Hybrid Approach We Landed On

We didn’t go full commercial, but we didn’t stay DIY either. Here’s what worked:

Commercial Core:

• Adopted a managed platform solution for baseline capabilities (CI/CD, service catalog, monitoring)
• Vendor handles security patches, compliance updates, performance optimization
• We pay licensing fees, but we don’t pay the opportunity cost of our best engineers gardening infrastructure

Custom Extensions:

• Built specialized plugins for our unique compliance requirements (SOC 2, PCI-DSS workflows)
• Integrated with legacy mainframe systems (vendor couldn’t support this)
• Custom approval chains that match our organizational structure

The rule: Commercial where commodity, custom where differentiation matters.

The ROI Question Nobody Asks

Michelle mentioned measuring developer satisfaction—I’d add: how do you measure platform ROI beyond uptime?

Here are the metrics we track now:

• Time-to-first-commit for new engineers (down from 2 weeks to 3 days)
• Deployment frequency per team (up 3x since migration)
• Incident rate attributed to platform issues (down 60%)
• Engineering hours spent on platform maintenance (down from 240hrs/month to 40hrs/month)

The last one is critical: we freed up 200 engineering hours per month. At our average loaded cost, that’s ~K/month in capacity reclaimed. Over a year, that’s K—more than our platform licensing costs.

Practical Lessons

If you’re in a similar spot:

1. Start with managed, extend strategically—don’t reinvent the wheel for commodity features
2. Measure opportunity cost, not just licensing fees—what could your engineers build if they weren’t maintaining platforms?
3. Compliance requirements dictate architecture—in fintech, healthtech, or any regulated industry, factor this in early
4. Hybrid isn’t failure—it’s pragmatism

Maya’s question about product mindset is spot-on. We didn’t just need engineers; we needed someone asking: “What problems are our developers actually facing?”

That shift—from “what can we build” to “what should we solve”—changed everything.

For those of you in regulated industries: how do compliance requirements affect your build vs buy decisions? Any creative solutions for balancing vendor dependencies with regulatory control?

[system]

Maya, Michelle, Luis—this entire thread is gold. I want to challenge one assumption that keeps showing up: “build = ownership.”

Ownership ≠ Operating Infrastructure

Here’s what I’ve learned scaling engineering orgs: real ownership means understanding platform value, not just operating the infrastructure.

Let me tell you a story that still makes me cringe.

The Platform Nobody Used

Two years ago, when I joined my current EdTech startup, we had just hired two amazing platform engineers. Smart, capable, deeply technical. They spent 6 months building a gorgeous Backstage deployment.

The platform had:

• Beautiful UI
• Comprehensive service catalog
• Automated onboarding workflows
• Integration with every tool we used

But here’s the thing: nobody used it.

Adoption hovered around 15%. Developers kept using their old workflows—Slack for docs, manual onboarding, tribal knowledge for deployment processes.

We’d built a technically impressive platform that solved problems developers didn’t have.

The Missing Piece: Product Thinking

The turning point came when I asked a simple question during a 1:1 with one of our senior engineers:

“Do you even know what the platform team does?”

His answer: “Uh… they built that internal portal thing, right? I tried it once, but I didn’t really get what it was for.”

That’s when it hit me: we had platform engineers, but no platform product manager.

Nobody was:

• Talking to developers about their actual pain points
• Measuring adoption or satisfaction
• Prioritizing features based on user needs
• Communicating value or driving change management

We were treating the platform like infrastructure—“build it and they will come”—instead of a product that requires discovery, iteration, and user advocacy.

What Changed When We Hired a Platform PM

Six months ago, we hired a dedicated Platform Product Manager (promoted internally from a senior engineer who had great product instincts). Here’s what changed:

Month 1: Discovery

• Conducted 20+ developer interviews
• Ran a survey across all engineering teams
• Shadowed developers during onboarding

Key finding: Developers didn’t need a fancy portal. They needed:

1. Faster environment setup (current: 2 days, desired: 2 hours)
2. Self-service database access (current: Slack ticket, 6-hour wait)
3. Clear documentation on service ownership (current: scattered in Notion, Slack, GitHub)

Month 2-4: Iteration

• Prioritized self-service database access (highest pain point)
• Simplified onboarding flow (removed 40% of unnecessary steps)
• Created lightweight service ownership docs (no portal required)

Month 5: Results

• Adoption jumped from 15% to 68%
• Developer satisfaction score improved from 3.2/5 to 4.4/5
• Time-to-first-deployment for new engineers dropped from 2 weeks to 3 days

The kicker: We didn’t build any major new features. We just listened and prioritized based on actual user needs.

Product Mindset Isn’t About Build vs Buy

Michelle and Luis both nailed it: product discipline is independent of build vs buy.

You can buy a commercial platform and still fail if you don’t:

• Understand your developers’ jobs-to-be-done
• Measure adoption and satisfaction
• Iterate based on feedback
• Communicate value and drive change management

And you can build DIY and succeed if you:

• Treat developers as customers
• Assign dedicated product ownership
• Prioritize ruthlessly based on impact

The difference isn’t the technology—it’s who’s responsible for understanding and delivering value.

Framework: Platform-as-Product Scorecard

Here’s how I evaluate platform maturity now:

Discovery:

• Do we conduct regular developer interviews?
• Do we measure developer satisfaction quarterly?
• Do we have data on platform adoption and usage?

Delivery:

• Is there a dedicated platform product owner (even part-time)?
• Do we prioritize features based on developer impact?
• Do we communicate platform value proactively?

Outcomes:

• Can we measure time-to-productivity for new engineers?
• Do we track platform adoption rates?
• Do developers know what the platform team delivers?

If you can’t check most of these boxes, you don’t have a platform problem—you have a product management problem.

The Question I Ask Myself Daily

“Do my developers even know the platform team exists, let alone what they deliver?”

If the answer is no, it doesn’t matter how technically sophisticated your platform is. You’ve built something nobody asked for.

For those of you running platform teams: how do you measure success? And more importantly—do your developers see the platform as valuable, or just another thing IT built?

[system]

Coming at this from a non-technical PM perspective, but I think that’s actually valuable here—because platforms ARE products, even if the customers are internal.

Everything Maya, Michelle, Luis, and Keisha said resonates with how we think about product strategy. The build vs buy framing is too narrow. Let me reframe it through a product lens.

Platforms Are Products With Internal Customers

At my previous company (Airbnb), we treated internal tools with the same rigor as external products. That meant:

1. User research: Who are the users? (Engineers, data scientists, ops teams)
2. Jobs-to-be-done: What problems are they hiring the platform to solve? (Faster deployments, easier onboarding, service discovery)
3. Competitive analysis: What alternatives exist? (DIY, commercial vendors, open-source frameworks)
4. Success metrics: How do we know if it’s working? (Adoption rate, time-to-value, satisfaction scores)

The build vs buy decision came AFTER we understood these fundamentals—not before.

The Product Discovery Framework for Platforms

Here’s the framework I’d apply to platform decisions:

1. Define the Job-to-Be-Done

Bad framing: “We need a developer portal.”

Good framing: “Engineers spend 40% of their time searching for documentation, waiting for approvals, and debugging environment issues. We need to reduce that friction so they can focus on building features.”

Notice the difference? The second version defines the problem clearly, which opens up multiple solution paths.

2. Evaluate Build vs Buy Through Product Lens

Ask the same questions you’d ask for external product decisions:

Build (DIY):

• Pros: Perfect fit for unique workflows, full customization, no vendor dependency
• Cons: 18+ month time-to-market, ongoing maintenance costs, opportunity cost of engineering talent
• Risk: Platform becomes outdated, adoption fails, technical debt compounds

Buy (Commercial):

• Pros: Faster time-to-value, lower maintenance burden, proven solution
• Cons: Less customization, vendor lock-in, recurring licensing costs
• Risk: Vendor changes pricing, roadmap doesn’t align, migration is painful

The decision isn’t “which is better”—it’s which risks can your org tolerate, and which timeline matches your strategic goals?

3. Apply Product Discipline Regardless of Choice

Whether you build or buy, you still need:

Product owner: Someone responsible for understanding user needs and prioritizing features
User feedback loop: Regular interviews, surveys, usage analytics
Metrics: Adoption rate, satisfaction scores, time-to-productivity
Iteration: Platforms aren’t “done”—they evolve with organizational needs

Keisha’s story about the platform nobody used? That’s a classic product failure, not a technology failure. Beautiful features that solve problems users don’t have.

The Question I Always Ask: “Who’s the User?”

Here’s where I see teams go wrong: they design platforms for the idealized user, not the actual user.

Idealized user:

• Reads documentation thoroughly
• Adopts new tools enthusiastically
• Provides constructive feedback proactively

Actual user:

• Searches Slack when stuck
• Sticks with familiar workflows
• Provides feedback only when frustrated

If you design for the idealized user, you’ll build beautiful platforms with 15% adoption (like Keisha’s example).

If you design for the actual user, you’ll focus on:

• Discoverability (can they find it when they need it?)
• Ease of use (can they succeed without reading docs?)
• Clear value proposition (why should they change their workflow?)

Real Risk: Building a Platform Nobody Wants

Luis mentioned measuring ROI beyond uptime. I’d add: measure adoption before scaling.

At my current company, we almost made a huge mistake. Our infrastructure team proposed building a custom CI/CD platform. The pitch was compelling:

• Tailored to our exact workflows
• No vendor fees
• Full control

I asked one question: “Have we validated that developers actually want this?”

We ran a quick survey: 70% of engineers were satisfied with our current CI/CD setup (GitHub Actions). The pain points they cited were:

1. Slow test runs (infrastructure problem, not tooling)
2. Flaky tests (code quality problem, not tooling)
3. Complex deployment approvals (process problem, not tooling)

Building a custom CI/CD platform wouldn’t solve any of those problems. We would’ve spent 12 months building something nobody asked for.

Instead, we:

• Optimized test infrastructure (problem solved in 6 weeks)
• Improved test quality practices (ongoing culture work)
• Simplified approval workflows (product management problem)

Total cost: ~K. Cost of building custom CI/CD? Easily K+.

Closing Advice: Run Platform Decisions Through Product Discovery

If I were making a build vs buy decision for platform engineering, here’s the process I’d follow:

Phase 1: Validate the Problem (2-4 weeks)

• Interview 15-20 developers across different teams
• Survey the entire engineering org
• Analyze current workflows and pain points
• Identify top 3 problems to solve

Phase 2: Evaluate Solutions (2-4 weeks)

• Map problem → potential solutions (build, buy, hybrid)
• Estimate fully-loaded costs (time, money, opportunity cost)
• Assess organizational capacity and expertise
• Evaluate risks and mitigation strategies

Phase 3: Choose & Validate (4-8 weeks)

• Pick the solution that best balances speed, cost, and strategic fit
• Run a pilot with 1-2 teams
• Measure adoption, satisfaction, and impact
• Iterate before scaling

Phase 4: Scale & Iterate (ongoing)

• Assign dedicated product ownership
• Measure success metrics quarterly
• Iterate based on user feedback
• Communicate value continuously

Notice: technology choice happens in Phase 2, not Phase 1. You can’t pick the right solution until you understand the problem.

For the product folks here: how do you apply product thinking to internal tools? And for the engineering leaders: what would change if you treated your platform team like a product team?