Internal Developer Portal Build vs Buy: A 2026 Decision Framework

Your VP of Engineering just came back from a conference excited about platform engineering. The pitch is compelling: one portal, golden paths, faster onboarding, happier developers. Six months and three engineers later, your Backstage instance has a 12% weekly active rate, a YAML catalog that went stale after the first quarter, and a platform team that just pushed a breaking plugin upgrade on a Friday. Sound familiar? You are in the middle of the internal developer portal build vs buy decision that every engineering org above 50 developers hits sooner or later, and most teams get it wrong because they treat it as a tooling question instead of a product question.

This is a decision framework. We have shepherded clients through both paths: the Backstage monorepo that became a career-limiting event for the platform lead, and the managed IDP rollout that hit 70% adoption in a quarter. The difference was not the tool. It was knowing which column of the build-vs-buy ledger matched their actual constraints.

The 10% adoption problem nobody wants to name

Port's 2025 State of Internal Developer Portals put numbers on something platform engineers already knew: 94% of developers report dissatisfaction with their self-service tooling, only 6% are very satisfied, and half of engineering teams doubt the accuracy of the data in their central system of record. Spotify's own numbers are bleaker. Spotify officials have said publicly that the average Backstage adoption rate at other organizations is 10%, against a voluntary 99% inside Spotify.

Meanwhile Gartner is still forecasting that 80% of large software engineering organizations will have platform teams by 2026, up from 45% in 2022. The math does not work. If adoption is 10% and mandate is 80%, something has to give, and it is usually the platform team's headcount in the next round of cuts.

The problem is not Backstage the framework. It is the assumption that because Spotify open-sourced it, your three-person platform team can maintain a production-grade portal while also building the features your developers actually want. Backstage is a React and TypeScript monorepo you inherit, not a product you install. That distinction is the whole game.

What you are actually buying when you "buy" a portal

Managed IDPs (Port, Cortex, OpsLevel, Roadie as Backstage-as-a-service, Harness IDP) ship with four things that self-hosted Backstage makes you build yourself.

The first is automated catalog ingestion. Instead of YAML files committed next to service code, which go stale within weeks, the portal pulls service metadata from GitHub, Kubernetes, Terraform state, AWS tags, and Datadog. Your "single source of truth" is derived rather than declared, so it cannot rot.

The second is an upgrade path that does not break your plugins. Roadie's 2025 State of Backstage survey of 105 practitioners calls upgrades "a defining challenge", with friction growing as plugins and customizations pile up. Managed vendors absorb the breaking changes. You absorb a changelog.

The third is scorecards and standards on day one. Service maturity rubrics ("does this service have a runbook, a dashboard, a PagerDuty rotation, a CODEOWNERS file, an SLO?") work immediately instead of in month six.

The fourth is SSO, RBAC, and audit logs already configured. Not exciting until your SOC 2 auditor asks for the access review report.

The tradeoff is that you are on a vendor's roadmap. If you want a plugin they do not offer, you file a feature request. Roadie and Harness give you an escape hatch because they are still Backstage under the hood. Port and Cortex are proprietary platforms with their own extension models.

What you are actually building when you "build" with Backstage

Backstage is a framework for building a portal. That sentence deserves a second read, because it is the sentence most platform teams skip on their way to yarn install.

Here is what "build" really entails:

# Day 1: Bootstrap the monorepo
npx @backstage/create-app@latest
cd my-idp && yarn start

# Day 30: You now own these choices
# - Auth provider (Okta? Entra ID? GitHub OAuth? All three?)
# - Catalog ingestion (GitHub discovery? Kubernetes? Custom?)
# - Database (PostgreSQL, and who runs it?)
# - Hosting (Kubernetes? ECS? Vercel?)
# - CI/CD for the portal itself
# - TypeScript and React upgrade cadence
# - Plugin compatibility matrix across 40+ community plugins
# - On-call rotation for the portal (yes, the portal needs on-call)

Every line above is a small decision. Together they add up to a product team's worth of work. The teams that succeed with Backstage treat it as a product with dedicated PM, design, and engineering headcount. The teams that fail treat it as a side project for the "platform engineer" who is also the Kubernetes admin and the Terraform reviewer.

One r/devops user, quoted in Port's own write-up, captured the failure mode precisely: "The idea of backstage is super cool, but for me, as a DevOps engineer, the fact that I need to write a lot of React code instead of GitHub workflows and Terraform files made me leave the project." DevOps engineers joined DevOps to automate infrastructure, not to maintain a React app.

The real cost comparison over 3 years

Here is the TCO model we walk clients through. The engineering numbers come from our own engagements with 80 to 300 engineer orgs between 2024 and 2026, with "fully loaded" meaning salary, benefits, and overhead at a $220K per engineer average. The license line uses Port's published list price of $40 per seat per month for its Standard tier, which covers up to 200 seats. Cortex publishes no prices and quotes per deal.

| Cost line | Self-hosted Backstage | Managed IDP (Port, Cortex, Roadie) | |---|---|---| | Initial build and rollout | 2 FTEs for 6 months: $220K | Setup and integration: $40K | | Year 1 maintenance | 1.5 FTEs: $330K | License ($40 per dev per month for 150 devs): $72K | | Year 2 and 3 maintenance | 1.5 FTEs for 2 years: $660K | License for 2 years: $144K | | Plugin and upgrade tax | 6 weeks a year for 1 FTE: $100K | Included | | Hosting and database | $24K | Included | | 3-year total | About $1.33M | About $256K | | Time to first adoption milestone | 6 to 9 months | 4 to 6 weeks |

The gap is roughly 5x, and that ignores the opportunity cost. The 1.5 FTEs running your Backstage fork are not building the golden paths, ingestion pipelines, or automation that actually move your DORA metrics. For a longer treatment of platform ROI in dollar terms, see our guide on measuring DevOps ROI metrics for the C-suite.

"But we have Backstage expertise in-house" is the most common objection. Our response: expertise is a cost, not an asset, if the work it enables does not appear on a roadmap the business recognizes. If the platform team cannot point to three features their developers asked for and got this quarter, the expertise is funding itself, not your business.

Decision framework: when to build, when to buy

Use this matrix. Score each row 0 to 2 (0 is no, 1 is partial, 2 is yes). Totals below 7 lean buy. 7 to 10 is a real decision. Above 10 is the rare build case.

| Criterion | What "yes" looks like | Your score | |---|---|---| | You have 3+ dedicated platform engineers with React and TypeScript experience | Not "can learn React". Have shipped React at scale | 0 to 2 | | You have a product manager assigned to the portal full time | The PM writes stories, runs user research, owns the roadmap | 0 to 2 | | Your compliance or data residency rules prohibit SaaS IDPs | GovCloud, EU-only workloads, air-gapped environments | 0 to 2 | | You need a custom plugin no vendor offers and it is core to the business | Not "nice to have". The portal is useless without it | 0 to 2 | | You have 500+ engineers, where per-seat pricing turns punitive | At $30 to $40 a seat, 500 devs is $180K to $240K a year, about one senior FTE | 0 to 2 | | Leadership has committed 3+ years of funding for the platform team | Not "we'll see how it goes". A signed multi-year plan | 0 to 2 | | You have portal users beyond engineering (security, SRE, PM) | Multi-persona makes SaaS feature gaps painful | 0 to 2 |

Most orgs we work with score 3 to 6. The honest answer for them is: buy now, revisit in year three when you know what you actually need. The teams that should build are the ones who score 10+ and have already built internal developer tools at scale: Shopify, Spotify, a handful of large tech subsidiaries, and regulated orgs with hard data residency constraints.

There is a third option we recommend for the 7 to 10 band: buy Backstage-as-a-service from Roadie or Harness. You get the extensibility of Backstage plugins without the upgrade tax, and you keep an escape hatch if you ever need to self-host. It is the middle path we have seen work for clients who cannot commit to a dedicated product team but also cannot live inside a fully proprietary portal's extension model.

Migration patterns: from Backstage to managed (and back)

If you are in the 12% adoption hole and your platform team is burning out, migrating off self-hosted Backstage is tractable, but it takes planning. The pattern we use:

1. Freeze plugin development. No new features on the Backstage fork. Any new work goes into the evaluation track.
2. Score your plugins. List every custom plugin. For each, mark it: owned by one team (deprecate), owned by the platform team (port), owned by security or SRE (check whether the vendor covers it).
3. Run a 30-day bake-off. Pick two managed IDPs (Port has a free tier for up to 15 seats, which is enough for a pilot), plug them into the same catalog sources, and let three pilot teams use both. Measure adoption, not signups.
4. Migrate catalog sources first, UI second. The managed vendors can ingest from the same GitHub repos and Kubernetes clusters your Backstage was reading. Run both portals in parallel for 60 days.
5. Retire Backstage on a deadline. Set a hard cutoff. Parallel operation beyond 90 days erodes trust in the new portal.

Going the other direction, from managed to self-hosted, is rare but happens at very large scale (500+ devs) when per-seat pricing crosses the one-FTE line. That migration is harder because proprietary IDPs do not export cleanly to Backstage's catalog format. Build a custom exporter or expect data loss.

What to measure: adoption vs usage

This is where most platform teams lie to themselves. "Usage" is "a developer loaded the portal once this month". "Adoption" is "a developer came back to the portal to complete a workflow they had a choice about". The difference is 10x in practice.

We recommend tracking four metrics weekly:

• Weekly active developers as a share of all developers. Target 60% or more after month six.
• Golden path completion rate. Of the developers who start "create a new service", how many finish? Target 80% or more.
• Catalog freshness. The share of services whose metadata was updated in the last 30 days. Target 90% or more.
• Time to answer "who owns this?", measured in seconds. Target under 30.

A portal that fails on catalog freshness fails on everything else. Stale data means the "who owns this" answer is wrong, so engineers stop trusting the portal, so they stop using it, so the metadata gets staler. That is the IDP death spiral and the single biggest reason Backstage forks die.

For the deeper measurement story, which metrics signal engineering health and which are vanity, see our post on AI coding assistants and DevOps workflows, which covers how automation changes what is worth measuring.

The 2026 wrinkle: AI-native IDPs

Most IDP vendors now ship some form of AI assistant. Many are thin wrappers around a general-purpose LLM that answer questions about your service catalog. Ignore that marketing. The genuinely useful AI feature in an IDP is the one that takes a developer's intent and runs the golden path, not the chatbot.

Port is furthest along that we have tested. Its AI agents, in closed beta since April 2025, answer catalog questions and can run Port self-service actions on a developer's behalf ("please acknowledge this incident for me"). The direction is clear even where the products are not finished: a request like "I need a new Go service with Postgres and a staging environment" should execute the golden path without a tour through five forms. When it works, it is the first IDP feature in five years that developers ask for unprompted, which is the real signal worth watching.

If you are committing to a multi-year IDP contract in 2026, ask the vendor to show you their agent architecture. Is it deterministic (templated paths with LLM-assisted input parsing) or autonomous (the LLM decides what to do)? Deterministic is production-ready. Autonomous is not, and its failure modes are the same ones we covered in our piece on safe AI-assisted IaC with Claude Code and Terraform.

When to Get Help

Internal developer portal build vs buy is a decision most engineering leaders make once every 3 to 5 years. Getting it wrong burns a year of platform team capacity and a chunk of leadership credibility.

We help VPs of Engineering and CTOs run the decision in 3 to 4 weeks: scorecard assessment, vendor bake-off, migration plan where one is needed, and a 90-day adoption target. If you are staring at a 10% adoption number on a Backstage fork and wondering whether to double down or cut bait, or you are greenfield and want to avoid that trap entirely, book a 30-minute consultation and we will walk through your scorecard live.

The goal is not a portal. The goal is a platform your developers choose because the paved path is faster and safer than the alternatives. Everything else is a budget line with a logo on it.