Build vs. Buy for Internal Developer Portals: 6-12 Month Setup, $200K Annual Managed Solutions, or Custom Build. Which Regret Is Most Affordable?

General
1

We’re about to make a platform engineering decision that will cost us somewhere between half a million and a million dollars over two years. The kicker? All three options feel like different flavors of regret.

The Three-Way Dilemma

Option 1: Self-Host Backstage

  • Cost: $800K+ first year (3-5 engineers × $150K loaded, plus 9 months opportunity cost)
  • Timeline: 6-12 months to production (18+ for complex setups)
  • Reality check: External adoption averages 10% vs Spotify’s internal 99%
  • Ongoing: $450K/year minimum just for maintenance (3-15 FTE depending on scale)

Option 2: Managed Solution (Port, Cortex, Roadie)

  • Cost: ~$200K/year licensing
  • Timeline: Weeks to first value
  • Tradeoff: Less customization, vendor lock-in
  • Ongoing: Still need integrations, data ingestion, adoption work

Option 3: Custom Build

  • Cost: Highly variable, but likely $500K+ in year one
  • Timeline: 12-18 months for anything production-worthy
  • Risk: Highest - you’re building what others have already built
  • Ongoing: Full ownership of maintenance, features, and technical debt

Why This Matters Now

Gartner predicts 85% of platform engineering teams will adopt internal developer portals by end of 2026. The platform engineering market is exploding from $5.76B (2025) to projected $47.32B by 2035. The pressure to “have a portal” is real.

But here’s the uncomfortable question: What’s the business case when every option has a massive downside?

The Impossible ROI Calculation

Self-hosting Backstage is “free” except it costs more than three years of a managed solution. Managed solutions are “fast” except you still need engineering time for integrations. Custom builds give you “exactly what you need” except by the time you build it, your needs have changed.

The real decision isn’t technical—it’s financial risk tolerance:

  • Can you afford to spend $800K and get 10% adoption?
  • Can you afford vendor lock-in at $200K/year?
  • Can you afford 12-18 months of engineering time for a non-product investment?

My Current Thinking

As a product leader, I’m looking at this through an ROI lens, and none of the math makes me feel good:

  • Backstage TCO: First-year $800K, ongoing $450K/year, massive adoption risk
  • Managed TCO: $200K license + $150K integrations/year = $350K, fast time-to-value
  • Custom TCO: $500K build + $300K/year maintenance = highest long-term cost

The managed solution wins on TCO and time-to-value, but I’m stuck on the “what if we outgrow it?” question.

What’s Your Framework?

For those who’ve made this decision:

  1. What did you choose and why?
  2. What were the hidden costs you didn’t anticipate?
  3. If you could redo the decision, would you change it?
  4. How did you calculate ROI when developer productivity gains are squishy?

The decision feels less like “which option is best” and more like “which regret is most affordable.”

Sources: The True Cost of Self-Hosting Backstage, Platform Engineering Predictions 2026, Why DIY Is Dead

2

I lived this nightmare. We chose self-hosted Backstage. Estimated 6 months, took 14. Burned through 5 engineers. Here’s what nobody tells you upfront.

The “Free” Option Cost Us $900K

Initial pitch to leadership: “Backstage is open source, we’ll save on licensing.” Reality: Our 3-person platform team became 5, then briefly 7 during the push to production.

Timeline breakdown:

  • Months 1-2: Setup, infrastructure, initial plugins (optimistic phase)
  • Months 3-6: Custom integrations with our tool stack (reality sets in)
  • Months 7-10: Debugging authentication, fixing performance issues (desperation)
  • Months 11-14: Getting to “good enough” to launch (exhaustion)

That’s 14 months of 5 engineers at $150K loaded each. Plus the opportunity cost—what could those engineers have built for the product instead?

The Integration Tax Nobody Warned Us About

Every tool in our stack needed a custom integration:

  • GitHub: Built-in, worked great
  • GitLab (we use both): Custom plugin, 3 weeks
  • PagerDuty: Broke 3 times in 6 months with API changes
  • DataDog: Custom build, 2 weeks
  • Jira: Built-in but we needed custom fields, another week
  • Our internal tools: 4 weeks each

Each integration wasn’t just build time—it was ongoing maintenance. Platform team spent 40% of their time keeping integrations working, not building new value.

The Adoption Crisis

After all that work, 12% adoption in the first 3 months. We mandated it, got to 25% grudging usage. Never hit 50%.

Why? We built what the platform team thought developers needed, not what they actually needed. Treated it like an infrastructure project, not a product.

What I’d Do Differently

If I could go back:

  1. Start with managed - Get to value in weeks, not months
  2. Prove adoption first - Use managed solution to validate portal is even valuable
  3. Migrate to self-hosted only if you hit managed solution limits (most companies never do)
  4. Factor in 2x multiplier - Whatever timeline you estimate, double it

The hard truth: Unless you’re Spotify-scale with a 10+ person platform team and dedicated design resources, seriously consider managed.

“Free” Backstage cost us more than 4+ years of Port or Cortex licensing. And we still don’t have the adoption to justify it.

The question isn’t build vs buy. It’s opportunity cost vs license cost. Engineering time you spend on portal is engineering time not spent on product.

3

We went the opposite direction—chose managed solution (Port) after evaluating all three options. Two years in, I’d make the same decision again, but for reasons I didn’t fully understand at the time.

The Decision Criteria

Our platform team was 2 engineers. Leadership wanted a portal “within the quarter.” Self-hosting Backstage was immediately off the table—we didn’t have the team capacity.

The real decision: Custom build vs managed.

What made us choose managed:

  1. Time-to-value: Production-ready in 3 weeks vs 6-12 months minimum for custom
  2. Team capacity: 2 engineers couldn’t both build portal AND serve developers
  3. Risk profile: Series B company—couldn’t afford 12-month platform engineering distraction
  4. Total cost: $200K license felt expensive until we ran the engineering math

The ROI Math That Convinced Leadership

Here’s the TCO comparison I presented to our CFO:

Managed Solution (Port):

  • License: $200K/year
  • Integration engineering: ~$100K/year (0.5 FTE for custom connectors)
  • Adoption/training: $50K/year (PM time, training materials)
  • Total: $350K/year
  • Time to value: 3-4 weeks

Self-Hosted Backstage:

  • Build cost: 3 engineers × 9 months × $150K = $337K (just the build phase)
  • Ongoing maintenance: 2-3 FTE × $150K = $300K-450K/year
  • Integration work: Same $100K/year as managed
  • Design/UX: Didn’t have resources, would need to hire ($150K+)
  • Total: $637K first year, $400K+ ongoing
  • Time to value: 9-12 months minimum

The kicker: 9 months faster to value. In a high-growth company, that’s 3 quarters where product engineers could focus on shipping instead of waiting for portal infrastructure.

The Real Metric: Developer Adoption

This is what I got wrong initially: I optimized for customization potential. What actually mattered was adoption.

Managed solutions like Port, Cortex, and OpsLevel compete on product experience. They have design teams, product managers, user research. Self-hosted Backstage looks the same everywhere—default UI with your logo swapped in.

Our adoption numbers after 6 months:

  • 78% of engineers use portal at least weekly
  • 92% use service catalog (our killer feature)
  • 45% use incident runbooks (still growing)

Why the high adoption? Because the tool just works. No broken integrations, no “platform team is investigating,” no downtime during upgrades.

What We Lost (And Why It Doesn’t Matter)

Yes, we have less customization than self-hosted Backstage. But here’s the uncomfortable question: Do you actually need that customization?

What we can’t do:

  • Build completely custom plugins with arbitrary UI
  • Control the exact data model for every entity
  • Deploy to our specific infrastructure preferences

What we haven’t needed to do:

  • Any of the above

Turns out, 90% of portal value is in service catalog + documentation discoverability + incident runbooks. The managed solution handles all of that out of the box. The exotic customization we thought we’d need? Hasn’t come up.

The Strategic View

Platform is a means to an end—the end being developer velocity and product shipping speed.

A beautiful self-hosted portal with 15% adoption is worse than a managed portal with 75% adoption. The metric is not “how customized is our portal,” it’s “how much faster are developers shipping?”

Portal infrastructure is not our competitive advantage. What we build on top of it—our product—is. Managed solution freed our platform engineers to focus on golden paths, developer tooling, and CI/CD optimization.

If You’re On the Fence

Ask yourself:

  1. Do you have 5+ engineers to dedicate to portal long-term? If no → managed
  2. Is portal customization your competitive advantage? If no → managed
  3. Can you afford 6-12 months before getting value? If no → managed
  4. Do you have dedicated design resources for portal UX? If no → managed

If you answered “no” to any of those, seriously consider managed. “Free” Backstage stops being free really quickly when you factor in engineering opportunity cost.

4

Coming from the user side (not the builder side), I want to talk about what actually drives adoption. Because I’ve seen both extremes.

The Failed Portal: 8% Adoption

Previous company, self-hosted Backstage. Platform team spent 18 months building it. Looked impressive in demos. Ghost town in practice.

Why nobody used it:

  1. Slow: 3-5 second load times. Developers kept using GitHub directly because it was faster
  2. Broken search: Service catalog search was fuzzy in the wrong ways. Easier to ask in Slack “who owns auth service?” than search portal
  3. Stale data: Ownership info was wrong 40% of the time. Once you can’t trust the data, you stop checking
  4. No mobile: Couldn’t check runbooks on phone during incidents. Back to Notion
  5. Ugly UI: Looked like a 2015 enterprise tool. Nobody wants to use ugly software

The real problem: Platform team spent all their time keeping the infrastructure running. Zero time improving the user experience.

No design resources. No user research. No iteration based on feedback. Just “we built you a portal, use it.”

The Working Portal: 85% Adoption

Current company, managed solution (can’t remember which one—OpsLevel I think?). I didn’t even realize we switched to it because it just worked.

Why everyone uses it:

  1. Fast: Sub-second load times, feels native
  2. Good search: Actually finds what you’re looking for
  3. Live data: Integrations just work. Trust the data
  4. Beautiful: Looks like a consumer product, not enterprise software
  5. Mobile-friendly: Check oncall schedule from anywhere

The difference: Their job is making a great portal product. That’s all they do. Our platform team’s job is serving our developers, not maintaining portal infrastructure.

The UX Nobody Talks About

Here’s what I think everyone misses: Developer tools need design.

Engineers assume “good tech speaks for itself.” But that’s not true. Spotify’s Backstage has 99% adoption internally because they have designers and product managers dedicated to it. Your 3-person platform team trying to self-host Backstage doesn’t have that.

Managed solutions have entire design teams because portal UX is their product differentiation. Self-hosted Backstage instances all look the same because nobody has time to customize the UI—they’re too busy keeping it running.

The Question Nobody Asked Us

Before building the self-hosted portal, platform team never asked developers:

  • “What’s blocking you today?”
  • “What would make you more productive?”
  • “How do you currently find service ownership info?”

They assumed we needed a portal. Maybe we just needed better README files and a service catalog spreadsheet.

The managed solution worked because the vendor had already done that user research across hundreds of companies. They knew what features actually drove adoption.

If You’re Building

If you’re set on self-hosting Backstage, please:

  1. Budget for design from Day 1 - Ugly portals don’t get adopted
  2. Do user research - Build what developers actually need, not what you think they need
  3. Measure adoption, not deployment - A launched portal with 10% usage is a failure
  4. Iterate on UX - Portal v1.0 is not the finish line

Or just use a managed solution where someone else has already solved the UX problem.

The build vs buy decision matters less than the adoption decision. A perfect portal nobody uses is worth $0.

5

I’ve made this decision at three different companies, at three different stages. The “right answer” changes based on company maturity, and I think that’s what most build-vs-buy discussions miss.

Company 1: Series A Startup (30 Engineers)

What we did: Custom lightweight portal—basically a well-organized docs site with embedded links to all our tools.

Cost: 2 weeks of eng time, $0 ongoing
Adoption: 90%+ because it was just docs with better navigation
Why it worked: We had 12 microservices. Notion with good structure solved 90% of “I don’t know where things are”

Lesson: Don’t overbuild for your current scale.

Company 2: Series B Growth Stage (85 Engineers)

What we did: Evaluated self-hosted Backstage for 6 weeks, chose managed Cortex instead.

Decision criteria:

  • Platform team was 3 people—couldn’t afford 12-month distraction
  • 40+ microservices made manual tracking painful
  • Needed service catalog + ownership + on-call integration
  • Leadership wanted “within the quarter”

Cost: $180K/year license + ~$80K integration work = $260K year one
Adoption: 72% after 6 months
Why it worked: Fast time-to-value (5 weeks to production). Tool actually solved developer pain (who owns this service? who’s on-call?)

Lesson: Managed solutions are for when you need to ship fast and don’t have platform team capacity.

Company 3: Series C/Pre-IPO (200+ Engineers)

What we considered: Migrating from managed Cortex to self-hosted Backstage for “cost savings and customization.”

What we actually did: Stayed with Cortex, negotiated better pricing.

Why:

  • Self-hosting would need 5-7 FTE long-term
  • Cost would be $750K+/year vs $300K for enterprise Cortex license
  • Risk of migration killing adoption (developers already using Cortex)
  • “Customization” we thought we needed didn’t have clear business case

Lesson: Even at scale, managed can still be cheaper when you factor in total cost.

The Framework I Use Now

Choose lightweight docs approach when:

  • <30 engineers
  • <20 microservices
  • Simple infrastructure
  • No compliance requirements

Choose managed solution when:

  • 30-200 engineers
  • Platform team <5 people
  • Need fast time-to-value (weeks, not months)
  • Standard integrations solve 80%+ of needs

Consider self-hosting only when:

  • 200+ engineers
  • Platform team 8+ people with dedicated design
  • Highly custom requirements (exotic integrations, security, air-gapped environments)
  • Multi-year commitment to portal as product

The Question Most People Get Wrong

It’s not “build vs buy.” It’s “what can we afford to NOT build?”

Every hour spent building portal infrastructure is an hour not spent:

  • Improving CI/CD pipeline
  • Reducing deployment friction
  • Building golden paths for common tasks
  • Actually serving developers

Portal is a means to an end. The end is developer productivity. If managed solution gets you there faster and cheaper, why build?

The Hidden Trap

The most expensive decision is choosing self-hosted Backstage before you have the team maturity to execute it well.

I’ve seen companies:

  • Start self-hosting with 2-person platform team (disaster)
  • Underestimate integration complexity by 3-4x (always)
  • Ignore adoption because “we built it, they have to use it” (mandate doesn’t work)
  • Burn 12-18 months before admitting defeat and switching to managed

The sunk cost fallacy is real. It’s much harder to migrate from failed self-hosted to managed than to start with managed and migrate to self-hosted later if you actually need to (most never do).

My Advice

Unless you check ALL these boxes, go managed:

:white_check_mark: Platform team of 5+ engineers
:white_check_mark: Dedicated design resources for portal UX
:white_check_mark: 12-18 month timeline is acceptable
:white_check_mark: Budget for $500K+ first year
:white_check_mark: Executive buy-in for long-term investment
:white_check_mark: Clear ROI case for customization over managed

If any of those are :cross_mark:, start with managed. You can always migrate later if you outgrow it.

But in my experience? Most companies never outgrow managed solutions. The 10-20% of customization they think they need ends up mattering less than fast time-to-value and high adoption.