The Real Cost of 'Free' Backstage: When Does Managed Make More Sense Than Self-Hosted?

[product_david]

Let’s talk about the elephant in the room: cost.

Everyone’s excited about Backstage because it’s “free.” But free is the most expensive word in software.

I’ve been running the numbers on our internal platform initiative, and the math is sobering. This post is my attempt to think through when self-hosting makes sense versus when managed solutions are the better investment.

The Real Cost of “Free” Backstage

Here’s what we’re looking at for a mid-size engineering org (150-200 engineers):

Initial Build:

• Core platform setup: 2 engineers × 3 months = $150K
• Plugin development: 4 engineers × 6 months = $600K
• Integration work: 2 engineers × 4 months = $200K
• Security/compliance hardening: 1 engineer × 3 months = $75K

Total initial: $1.025M

And that’s assuming everything goes smoothly. No delays, no scope creep, no discovering that the plugin you need doesn’t exist.

Ongoing Annual Costs:

• Maintenance and updates: 1.5 FTE = $225K/year
• New plugin development: 1 FTE = $150K/year
• Infrastructure/hosting: $30K/year
• Security patches and compliance: 0.5 FTE = $75K/year

Total annual: $480K/year

The Managed Alternative

For comparison, managed internal developer portal solutions:

Year 1:

• Platform cost: $100K-$200K (depending on team size)
• Integration work: 1 engineer × 3 months = $75K
• Customization: 1 engineer × 2 months = $50K

Total year 1: $225K-$325K

Ongoing annual:

• Platform subscription: $120K-$200K
• Minor customizations: 0.25 FTE = $40K

Total annual: $160K-$240K

The Break-Even Analysis

Self-hosted Backstage:

• Year 1: $1.025M + $480K = $1.505M
• Year 2: $480K
• Year 3: $480K
• 3-year total: $2.465M

Managed solution:

• Year 1: $325K
• Year 2: $240K
• Year 3: $240K
• 3-year total: $805K

The managed solution is $1.66M cheaper over 3 years.

But Wait, There’s More (Costs)

What I haven’t included:

Opportunity Cost:
Those 6 engineers building Backstage could have been:

• Building features that directly drive revenue
• Paying down technical debt
• Improving core product performance

If your engineers generate $500K/year in value on product work, that’s $3M in opportunity cost over the build period.

Hidden Costs:

• Debugging plugin incompatibilities (this killed us for 6 weeks)
• Migrating when Backstage changes architecture (happened twice)
• Training new platform team members
• User support and documentation

Add another $200K/year for these.

When Does Self-Hosted Make Sense?

I’m not saying “never build.” But the economics only work when:

1. You have unique requirements that no managed solution addresses

   • Example: Deep integration with proprietary internal systems
   • Example: Extreme compliance requirements (defense, healthcare)

2. You have massive scale where per-seat pricing becomes prohibitive

   • Managed at $200K for 200 engineers = $1K/engineer
   • Self-hosted at $480K for 1000 engineers = $480/engineer
   • Break-even somewhere around 400-500 engineers

3. You have platform engineering expertise already

   • If you’re hiring the team from scratch, managed is cheaper
   • If you have experienced platform engineers with spare capacity, building might make sense

4. You’re okay with the opportunity cost

   • Can your business afford to have senior engineers not working on product for 6-12 months?

The Build-vs-Buy Decision Tree

Here’s my framework:

Build if:

• Team size >500 engineers
• Unique compliance needs
• Existing platform team with capacity
• Multi-year commitment to maintenance

Buy if:

• Team size <300 engineers
• Standard use cases (service catalog, docs, scaffolding)
• Need fast time-to-value
• Limited platform engineering expertise

Hybrid approach:

• Use managed for core functionality
• Build custom plugins for unique needs
• Contributes to OSS where possible

The Question Nobody Asks

Here’s what I struggle with:

How do you calculate ROI for internal platforms?

We can measure costs clearly. But value is fuzzy:

• Reduced onboarding time: How much is that worth?
• Fewer Slack questions: What’s the dollar value?
• Better service ownership: How do you quantify that?

Without clear ROI metrics, we’re just guessing whether $1M investment is worth it.

What Would Change My Mind

I’d reconsider self-hosting if:

1. We could ship the MVP in <3 months with <2 engineers
2. We had clear metrics showing $500K+/year in value
3. We had dedicated platform team that wouldn’t get pulled to product work
4. Leadership committed to multi-year investment

Without those four things, I can’t justify the cost.

My Ask

For those who’ve built internal platforms or bought managed solutions:

How did you calculate ROI? What metrics proved (or disproved) the investment?

Because right now, I’m looking at $1.66M in savings by going managed, and I need a really compelling reason to justify spending that money on self-hosting.

[cto_michelle]

David, thank you for laying out the numbers so clearly. As the person who approved our $2M Backstage investment, I need to respond to this.

The Uncomfortable Reality

Your math is correct. Possibly conservative.

Our actual spend on Backstage:

• Initial build: $1.8M (went over budget)
• Year 1 ongoing: $620K (more than projected)
• Year 2 projection: $580K (maintenance is expensive)

Total 2-year cost: $3M

For context, our engineering org is 240 people. That’s $12,500 per engineer.

Why We Built Anyway

Here’s the reasoning that seemed sound 18 months ago:

1. “We’re special” - Our systems are unique, off-the-shelf won’t work

   • Reality: 80% of our integrations are standard (GitHub, Datadog, PagerDuty)
   • The 20% that’s unique could have been plugins on a managed platform

2. “We’ll contribute to OSS and get community support”

   • Reality: We’ve contributed 2 plugins, received minimal community support
   • Maintenance is still 100% on us

3. “Build once, use forever”

   • Reality: Backstage evolves, we’re constantly updating to stay compatible
   • “Forever” means “continuous investment”

4. “It’ll pay for itself in efficiency gains”

   • Reality: At 31% adoption, hard to measure any ROI

The ROI Question

You asked how to calculate ROI. Here’s what we tried:

Attempted Metrics:

1. Onboarding time reduction: 5 days → 3 days for new engineers

   • 40 new hires/year × 2 days × $500/day = $40K/year value
   • ROI: -$3M cost + $40K value = terrible

2. Reduced Slack questions: ~15% decrease in #engineering-help volume

   • Hard to quantify value
   • Maybe $50K/year in time saved?

3. Faster incident resolution: Service catalog helps find owners

   • No measurable improvement yet
   • Theoretical value: High. Actual value: TBD

Total measurable value: ~$90K/year

That’s a 33-year payback period on a $3M investment.

What We Got Wrong

The fundamental error: We optimized for flexibility, not time-to-value.

We wanted to build “the ultimate platform” that could do everything. We should have bought a solution that did the top 3 things well and shipped it in 6 weeks.

The Hybrid Approach

If I could redo this, here’s what I’d do:

Year 1: Buy managed solution

• $200K subscription
• 3 months to integrate and launch
• Prove value with high adoption
• Learn what we actually need

Year 2: Evaluate build

• If adoption >70% and we have unique needs, consider building
• If managed solution works, keep it
• Make decision based on data, not assumptions

This approach:

• Reduces risk (small initial investment)
• Proves value before big spend
• Gives us data to make build-vs-buy decision

The Sunk Cost Problem

Now I’m stuck. $3M invested, 31% adoption, questionable ROI.

Options:

1. Kill it - Write off $3M, move to managed
2. Double down - Mandate adoption, try to realize value
3. Hybrid - Keep for specific use cases, supplement with managed for others

I’m leaning toward option 3. Use what we built for the unique integrations, buy managed for standard stuff.

The Scale Question

You mentioned break-even around 400-500 engineers. I’d push that higher.

Even at our scale (240 engineers), managed would be cheaper:

• Managed 3-year cost: ~$700K
• Our actual 2-year cost: $3M

I think the break-even is closer to 800-1000 engineers, and only if you have:

• Dedicated platform team (not borrowed from product)
• Very unique requirements
• High adoption (>70%)

My Advice

If you’re under 500 engineers: Buy, don’t build.

The economics don’t work. The opportunity cost is too high. The risk is too great.

If someone on your team says “but we’re special,” ask them to quantify how much that specialness is worth. If they can’t show $500K/year in value from unique features, you’re not special enough to justify building.

[eng_director_luis]

David, your numbers align with what I’ve seen, but I want to push back on one thing: The opportunity cost framing might be wrong.

The False Choice

You’re presenting it as: “Engineers either build Backstage OR build product features.”

But that’s not how it works in practice. Here’s what actually happens:

Without internal platform:

• Engineers waste 2-3 hours/week on toil (finding docs, figuring out deployments, hunting down service owners)
• That’s 100-150 hours/year per engineer
• For 200 engineers: 20,000-30,000 hours/year wasted

Value of time saved:

• 25,000 hours × $100/hour = $2.5M/year in recovered productivity

So the question isn’t “should we spend $1M building a platform?” It’s “is there a cheaper way to recover $2.5M/year in lost productivity?”

The Build Cost You’re Missing

Your $1M build estimate assumes everything goes smoothly. It won’t.

Add these hidden costs:

Technical Debt:

• First version will have shortcuts and hacks
• Cleanup: 1 engineer × 3 months = $75K

Integration Maintenance:

• APIs change, plugins break
• Ongoing: 0.5 FTE = $75K/year

User Support:

• Questions, bug reports, feature requests
• Ongoing: 0.5 FTE = $75K/year

Platform Evolution:

• Adding new tools, deprecating old ones
• Ongoing: 0.5 FTE = $75K/year

Realistic ongoing: $780K/year, not $480K

The Managed Cost You’re Missing

Managed solutions aren’t just subscription fees either:

Lock-in Risk:

• Vendor raises prices 30% year 2 (I’ve seen this)
• Migration cost if you leave: $200K+

Limited Customization:

• Can’t integrate with proprietary internal tools
• Workarounds: 0.25 FTE = $40K/year

Feature Dependency:

• You need a feature, vendor won’t build it
• Options: Wait indefinitely or build it yourself anyway

Data Privacy:

• Sending internal architecture info to third party
• Compliance review cost: $50K
• Ongoing audit: $20K/year

My Actual Numbers

We evaluated both approaches for our 180-engineer org:

Self-Hosted Reality:

• Year 1: $1.4M (over your estimate)
• Ongoing: $650K/year (way over your estimate)

Managed Reality:

• Year 1: $380K ($280K subscription + integration)
• Year 2: $340K (price increase + customization)
• Year 3: $400K (another price increase)

3-year totals:

• Self-hosted: $2.7M
• Managed: $1.12M

Managed wins, but not by as much as your analysis suggests.

The ROI Framework

Here’s how we calculated value:

Time Saved Per Engineer:

• Faster onboarding: 2 days saved × 30 new hires = 60 days = $30K
• Reduced toil: 2 hours/week × 180 engineers × 50 weeks = 18,000 hours = $900K
• Faster incident resolution: 30 min/incident × 200 incidents = 100 hours = $50K

Total annual value: $980K

Managed solution ROI:

• Cost: $340K/year ongoing
• Value: $980K/year
• Net: $640K/year benefit
• Payback: <6 months

Self-hosted ROI:

• Year 1: -$1.4M cost + $980K value = -$420K
• Year 2: -$650K + $980K = $330K
• Year 3: -$650K + $980K = $330K
• Cumulative: $240K positive after 3 years

Even with optimistic value estimates, self-hosted barely breaks even after 3 years.

When Build Makes Sense

I disagree with your 500-engineer threshold. Even at 1000 engineers, I’d buy if:

1. Your needs are standard (most companies’ are)
2. You can launch in <3 months (speed matters)
3. You don’t have platform expertise (hiring is hard)

Build only if you have genuinely unique requirements that no vendor addresses.

The Real Question

It’s not “build vs. buy.” It’s:

“What’s the fastest way to recover the $2.5M/year we’re losing to engineering toil?”

If managed gets you there in 3 months and self-hosted takes 12 months, the managed solution saves you an additional $1.875M in the first year by stopping the bleeding faster.

My Recommendation

Start with managed. Prove the value. Then decide if you need to build.

If adoption is <50% with managed, building won’t fix it. You have a product problem, not a technology problem.

If adoption is >70% with managed and you’re hitting limitations, now you have data to justify building.

But never build first and hope for adoption. The failure rate is too high.

[vp_eng_keisha]

David, Luis, Michelle—this entire thread should be required reading for every CTO considering platform investments.

I’m going to share some numbers that will make people uncomfortable.

The Industry Data

Gartner surveyed 500 companies on internal platform costs. Here’s what they found:

Self-Hosted Platforms (avg 300 engineers):

• Median initial cost: $1.6M
• Median ongoing: $520K/year
• Median time-to-launch: 14 months
• Median adoption at 18 months: 42%

Managed Solutions (avg 300 engineers):

• Median initial cost: $340K
• Median ongoing: $280K/year
• Median time-to-launch: 3 months
• Median adoption at 18 months: 68%

The adoption gap is the killer. Lower adoption = lower value = worse ROI.

Why Adoption Matters More Than Cost

Let’s play out two scenarios for a 200-engineer company:

Scenario A: Cheap solution, low adoption

• Cost: $500K/year
• Adoption: 35%
• Engineers affected: 70
• Time saved per engineer: 3 hours/week
• Total time saved: 10,920 hours/year
• Value at $100/hour: $1.09M/year
• ROI: 118%

Scenario B: Expensive solution, high adoption

• Cost: $800K/year
• Adoption: 75%
• Engineers affected: 150
• Time saved per engineer: 3 hours/week
• Total time saved: 23,400 hours/year
• Value at $100/hour: $2.34M/year
• ROI: 193%

The expensive solution with high adoption delivers $1.25M more value annually.

The Build Trap

Michelle’s story is common. Here’s why self-hosted projects fail:

1. Underestimate complexity

   • “It’s just a UI over our APIs” → 6 months of integration work

2. Underestimate maintenance

   • “We’ll build it and be done” → Ongoing evolution required

3. Overestimate adoption

   • “If we build it, they’ll use it” → Nope

4. Ignore opportunity cost

   • “Our engineers have spare cycles” → No they don’t

The Hidden Cost: Team Morale

One cost nobody’s mentioned: What happens to the team that builds an unused platform?

I’ve seen this twice:

• Team spends 12 months building
• Launch happens, adoption is weak
• Team gets defensive, blames users for “not getting it”
• Leadership loses confidence in team
• Team gets frustrated and quits

Lost institutional knowledge, recruiting costs, morale hit across engineering: Easily $500K in hidden costs.

The Vendor Risk Counterargument

Luis mentioned vendor price increases. This is real. But let’s compare risk:

Vendor Risk:

• Price increase: Maybe 20-30% ($60K-$90K/year)
• Vendor shutdown: Migration cost $200K-$300K
• Expected value of risk: ~$50K/year

Build Risk:

• Project goes over budget: 50% chance, $500K cost
• Low adoption: 60% chance, $1M opportunity cost
• Key team member quits: 30% chance, $200K cost
• Expected value of risk: ~$620K

Building carries 12x more risk than buying.

When I’d Build

I run platform for 400 engineers. We use managed solutions for everything except one custom tool.

I’d only build if:

1. Truly unique requirements

   • Not “we use Kubernetes” (everyone does)
   • More like “we have proprietary deployment system that no vendor integrates with”

2. Scale economics

   • Vendor charges per-seat and we have 1000+ engineers
   • Can show self-hosted costs <60% of managed at that scale

3. Dedicated team

   • Not borrowed from product engineering
   • 3+ people with platform experience
   • Multi-year commitment

4. Proven adoption pattern

   • Used managed solution first
   • Hit 70%+ adoption
   • Clear evidence our engineers will use internal tools

Without ALL FOUR, buying is the right call.

The Hybrid Path

Here’s what I actually recommend:

Phase 1 (Months 1-3): Buy managed

• $200K-$300K investment
• Launch in 3 months
• Measure adoption and value

Phase 2 (Months 4-12): Optimize

• If adoption >60%, expand features
• If adoption <40%, fix product/UX issues
• Don’t build anything yet

Phase 3 (Year 2): Evaluate build

• If adoption >70% and hitting vendor limits, consider building
• If managed solution works, keep it
• If adoption still <50%, you have a product problem—building won’t fix it

Phase 4 (Year 3+): Hybrid approach

• Keep managed for standard features
• Build custom plugins for unique needs
• Contribute plugins to OSS

This approach minimizes risk, proves value, and gives you data to make informed decisions.

The ROI Formula

David asked how to calculate ROI. Here’s my framework:

Value = (Engineers × Adoption %) × Hours Saved × Hourly Cost

For 200 engineers at 70% adoption saving 3 hours/week:

• Value = 200 × 0.70 × 156 hours/year × $100 = $2.18M/year

ROI = (Value - Cost) / Cost

For managed solution at $300K/year:

• ROI = ($2.18M - $300K) / $300K = 627%

For self-hosted at $650K/year (ongoing):

• ROI = ($2.18M - $650K) / $650K = 235%

Both are positive, but managed delivers 2.7x better ROI.

My Controversial Take

Most companies should never build internal platforms.

Buy managed solutions, integrate them, customize with plugins. Focus your engineering talent on your actual product.

Platform engineering should be about curation and integration, not building from scratch.

The DIY era is over. Accept it and move on.

[maya_builds]

David, I appreciate you running the numbers. As someone who’s been on both sides—designing platforms AND using them—I want to add the designer’s perspective on cost.

The Cost Nobody Calculates: Bad UX

Here’s what happens with self-built platforms:

Platform team thinks:
“We’ll build something functional first, polish the UX later”

Reality:

• “Later” never comes
• Engineers won’t use something with bad UX
• Low adoption → low value → no budget for UX improvements
• Death spiral

I’ve watched this happen three times. The platform team says “it’s just internal, UX doesn’t matter.” Then they’re shocked when adoption is 20%.

Cost of bad UX:

• 200 engineers × 80% avoid the tool = 160 engineers still doing manual work
• 160 × 3 hours/week × 50 weeks × $100/hour = $2.4M/year in unrealized value

You spent $1M building the tool and $2.4M failing to deliver value because the UX was terrible.

The Design Advantage of Managed

Managed solutions have one massive advantage: They have designers.

They’ve done the user research. They’ve A/B tested the flows. They’ve optimized for adoption.

When you build internally:

• Platform team: 6 engineers, 0 designers
• Managed vendor: 40 engineers, 12 designers, 8 PMs

You’re not competing on equal footing.

The Real Cost Comparison

Let’s factor in design:

Self-Hosted with Proper UX:

• Initial build: $1M
• Design work: 1 designer × 6 months = $120K
• Usability testing: $30K
• Continuous UX improvements: 0.5 designer = $75K/year
• New year 1 total: $1.15M
• New ongoing: $555K/year

Managed Solution:

• Design is included in the subscription
• No additional cost

Now the gap widens from $1.66M to over $2M over 3 years.

The Adoption Math

Michelle’s 31% adoption is typical for internally-built platforms. Know why?

No designer means:

• Confusing navigation
• Inconsistent UI patterns
• No onboarding flow
• No help documentation
• No user research to understand pain points

With design:

• Intuitive flows
• Progressive disclosure
• Guided onboarding
• Contextual help
• Continuous improvement based on user feedback

The difference in adoption: 30% vs 70%.

That 40% adoption gap represents:

• 80 engineers × 3 hours/week × 50 weeks × $100/hour = $1.2M/year

The cost of not having a designer is $1.2M/year in unrealized value.

What Good Design Looks Like

I’ve used both self-built and managed platforms. Here’s the difference:

Self-Built Platform:

• 15 tabs in the navigation (too many choices)
• Three places to find service ownership (inconsistent)
• No search (have to browse)
• Tables with 20 columns (information overload)
• No mobile support (useless for on-call)

Well-Designed Platform:

• 5 top-level sections (focused)
• One source of truth (consistent)
• Search-first interface (fast)
• Relevant information prioritized (scannable)
• Responsive design (works everywhere)

The second one gets used. The first one gets abandoned.

The Speed-to-Value Argument

Luis is right about time-to-value, but let me add the design angle:

Self-hosted:

• Month 1-6: Build basic functionality
• Month 7-9: Realize UX is terrible
• Month 10-12: Try to fix UX while maintaining functionality
• Month 13+: Continuous struggle between features and polish

Managed:

• Month 1: Integration
• Month 2: Customization
• Month 3: Launch with good UX included

You start delivering value 9 months earlier. At $2M/year value, that’s $1.5M in earlier returns.

The Designer’s ROI Framework

David asked about ROI. Here’s the design lens:

Value = Potential Time Saved × Adoption Rate

Two platforms can have identical functionality but wildly different adoption based on UX.

Platform A: Great features, terrible UX

• Potential value: $2.5M/year
• Adoption: 30%
• Realized value: $750K/year

Platform B: Good features, great UX

• Potential value: $2M/year
• Adoption: 75%
• Realized value: $1.5M/year

Platform B delivers 2x more value with fewer features because people actually use it.

My Recommendation

If you’re going to build:

1. Hire a designer first, not last

   • Before you write a line of code
   • Let design drive the experience
   • Engineering implements the design, not the other way around

2. Budget for continuous UX work

   • Not one-time design
   • Ongoing user research, testing, improvements

3. Measure UX metrics

   • Time to complete tasks
   • Error rates
   • User satisfaction scores
   • Adoption rates

If you’re not willing to invest in design, don’t build. Buy instead.

The Uncomfortable Truth

Most platform teams are full of backend engineers who don’t value UX. They build tools that make sense to them, not to users.

Then they blame users for “not adopting” instead of recognizing that bad UX kills adoption.

If you’re going to spend $1M building a platform, spend $150K on design. The ROI on that $150K is easily 10:1 in improved adoption.

Or acknowledge that managed vendors have already made that investment, and buy from them.