Internal Developer Platforms: A Decision Guide for Platform Teams

01The Four Decisions in This Guide

• Adopt or not: below roughly 100 engineers, better golden path templates usually beat a platform.
• Which layer: developer portal, workload orchestrator, or a bundled PaaS alternative.
• Backstage or commercial portal: self-hosted Backstage is defensible at 1,000+ engineers with 3 to 12 platform FTEs; below that, managed Backstage or a commercial portal typically wins on total cost of ownership.
• How to run the pilot: 2 to 3 teams, one paved path end to end, weekly active use as the primary metric.

02Executive Summary

An internal developer platform is a product a platform team builds so product engineers can build, deploy, and operate services on the organization's chosen infrastructure without becoming infrastructure specialists. The decision facing most engineering leaders is not whether to invest in developer experience, but which layer of the platform market to buy, which layer to build, and which layer to leave alone.

The market divides into three distinct layers: developer portals that expose a catalog and golden path templates (Backstage, Roadie, Port, Cortex, OpsLevel, Configure8, Rely.io); workload orchestrators that translate a workload specification into provisioned infrastructure (Humanitec, Kratix, Score); and bundled platform-as-a-service alternatives that replace both with an opinionated stack (Northflank, Qovery, Encore). Selecting inside the wrong layer is the single most common reason a well-funded platform initiative fails to move adoption metrics.

StackAuthority's analysis of adoption data from the CNCF Platforms Working Group, the Puppet 2024 State of DevOps report, and the Humanitec Platform Engineering benchmarks converges on one recurring pattern: platform teams that appoint a product manager, define a target developer segment, and measure weekly active adoption outperform teams with larger budgets that treat the platform as an infrastructure delivery project.

03Why This Decision Matters Now

Platform engineering as a named discipline is still early. Humanitec's Vol 3 benchmark of 281 organizations found that 56 percent had run a platform team for under two years, and only 13 percent for more than five years (The New Stack coverage). Puppet's 2024 State of DevOps report found that organizations averaged three self-service platforms internally, which suggests both real investment and real fragmentation.

The commercial vendor market matured in parallel. Managed Backstage (Roadie), no-code portals (Port), scorecard platforms (Cortex, OpsLevel), and workload orchestrators (Humanitec, Kratix, Score) now cover most of the capability surface that platform teams previously built from scratch. Buying versus building is a live tradeoff again, and the wrong call on that tradeoff typically costs a platform team six to twelve months of engineering time and one adoption cycle.

Relevant baseline sources

• CNCF Platforms White Paper
• CNCF Platform Engineering Maturity Model
• Puppet 2024 State of DevOps Report
• Team Topologies

04What an Internal Developer Platform Is

The CNCF Platforms White Paper defines a platform for cloud native computing as a coherent collection of capabilities defined and presented according to the needs of the platform's users. Compared with a general internal tooling suite, a platform is scoped around a target developer audience and a specific set of paved paths for building, deploying, and operating services. Compared with a shared infrastructure account, a platform packages the underlying primitives behind a stable, versioned interface so that product teams do not have to reason about the substrate.

The cautionary read is that a catalog of Helm charts with documentation is not a platform. Without Day-2 operations, ownership metadata, and self-service exception handling, developers route around the catalog within a quarter and the investment quietly turns into shadow infrastructure that the platform team still has to maintain.

05Who This Guide Is For

Fit criteria

your organization runs more than 100 product engineers across multiple teams; provisioning, deploying, and observing a service today requires knowledge of more than three specialist tools; a platform team already exists or is being formed with at least two engineers; and leadership is willing to fund the platform as a product with adoption goals rather than as a one-time tool rollout.

This guide is less useful for organizations under 50 engineers, single-team startups where the founding engineers still touch every service, or teams where a mature paved path already exists on top of a managed platform-as-a-service such as Vercel, Fly.io, or Render.

06The Three Layers of the Platform Market

Developer portals

Portals surface a service catalog, ownership metadata, scorecards, documentation, and golden path templates in a single developer-facing interface. Compared with workload orchestrators, portals do not typically provision infrastructure themselves; they call out to existing CI, GitOps, and cloud accounts. The cautionary read is that a portal on top of a broken provisioning path only makes the broken path more visible; portals do not fix underlying deployment friction on their own.

Vendors in this layer include Backstage (open source, CNCF Incubating), Roadie (managed Backstage), Port, Cortex, OpsLevel, Configure8, and Rely.io.

Workload orchestrators

Workload orchestrators translate a workload specification, typically written by the developer, into concrete infrastructure resources across environments. Compared with developer portals, orchestrators are the delivery mechanism rather than the interface; they answer the question of how the platform actually creates a database, a Kubernetes namespace, or a message queue. The cautionary read is that an orchestrator without a portal or a paved workflow requires developers to write specification files by hand, which is a poor developer experience for anyone who is not already a platform engineer.

Vendors and specifications in this layer include Humanitec, Kratix, and the CNCF Sandbox Score specification.

Bundled platform-as-a-service alternatives

Platform-as-a-service alternatives collapse the portal, the orchestrator, and the runtime into one opinionated stack. Compared with a portal plus orchestrator combination, a PaaS alternative reduces time to first deploy dramatically but constrains the architectural choices available to product teams. The cautionary read is that these platforms are the right choice at small and medium scale but often become the constraint that a platform team is asked to remove once the organization outgrows the opinions baked into the vendor stack.

Vendors in this layer include Northflank, Qovery, and Encore.

Decision Framework: Should You Adopt an Internal Developer Platform at All

Signals that an internal developer platform is likely to pay off

more than 100 product engineers; more than 10 services under active development; provisioning a new service takes more than two working days; deployment configuration is copy-pasted across services rather than templated; on-call incidents recurrently trace to inconsistent deployment patterns; and security or compliance requires audit evidence that is currently produced by hand.

Signals that a lighter approach is likely to pay off

fewer than 50 engineers; fewer than 20 services; provisioning a service already takes under a day using a small set of Terraform modules and CI templates; and the same three engineers can explain the deployment path for every service in the organization.

For teams in the second group, the practical alternative is a small set of documented golden path templates on top of existing CI and infrastructure-as-code, maintained by a designated tech lead rather than a platform team. Buying a portal at this scale is a signal of premature optimization and often creates a maintenance burden that outlives the productivity gain.

08Decision Framework: Which Layer to Buy

Buy a developer portal when

the primary pain is service sprawl, ownership ambiguity, standards inconsistency, or on-call routing confusion; your CI, GitOps, and cloud provisioning already work reasonably well; and the goal is a single interface that catalogs, scores, and templates work already happening across teams.

Buy a workload orchestrator when

the primary pain is that developers spend days provisioning environments, databases, and dependencies; provisioning is currently done via ticket queues to a central platform team; and the goal is to replace request-and-fulfill with a self-service specification that a machine can execute end to end.

Buy a bundled platform-as-a-service alternative when

your organization is under 200 engineers, your architecture is service-oriented but not deeply specialized, you do not have a platform team and do not want one, and you are willing to accept the vendor's opinions about runtime, deployment, and observability in exchange for time to value measured in days.

09Decision Framework: Backstage vs Commercial Portal

The most common portal decision is whether to self-host Backstage, buy managed Backstage from Roadie, or buy a commercial portal such as Port, Cortex, or OpsLevel.

Side-by-side comparison

Public source references: Backstage, Roadie, Port, Cortex, OpsLevel.

Self-hosted Backstage makes sense when

your organization has more than roughly 1,000 engineers, a platform team with 3 to 12 dedicated engineers who can write and maintain React and TypeScript plugins, unusual workflow requirements that commercial portals do not model well, and a runway of at least 6 months before adoption metrics are expected. Backstage remains the choice with the largest plugin ecosystem and the most freedom to extend, and it is the default at hyperscale organizations for that reason.

Managed Backstage such as Roadie makes sense when

you want the Backstage plugin ecosystem and data model without the operational burden of running the framework yourself, and you can accept per-developer seat pricing typically ranging from around 20 to 25 dollars per developer per month above a minimum seat count. This option is common at the 300 to 1,000 engineer range where Backstage's flexibility is attractive but hiring a Backstage platform team is not.

A commercial portal such as Port, Cortex, or OpsLevel makes sense when

your organization has between 100 and 2,000 engineers, you want a portal in production within 2 to 6 weeks rather than 3 to 6 months, and the primary pain is standards enforcement, ownership, or catalog discovery rather than a need to model a highly unusual workflow. Port centers on a flexible blueprint data model configured through no-code interfaces. Cortex and OpsLevel center on scorecards and automated checks that can gate CI or CD. Configure8 pairs catalog with cost attribution in a single view.

Reality check on Backstage adoption

Spotify reports approximately 99 percent internal Backstage adoption. External adopter benchmarks are substantially lower, with typical adoption clustering in the range of 10 to 30 percent of engineers, and public case studies exist of Backstage deployments that reached only 5 percent engineer usage after a technically successful rollout (source is a Port blog post, vendor-authored). The delta is not a comment on the framework; it is a comment on the difference between building a portal as a product for a known internal audience and building one as an infrastructure project without one.

10Evaluation Criteria for Portal and Orchestrator Selection

Use a 1 to 5 scale per criterion and require a written rationale so scoring does not drift across reviewers.

Total score should inform decisions, not replace engineering judgment. In particular, a portal that scores well on catalog quality but poorly on integration fit will still cost the platform team a quarter of custom work to reach production.

11Common Failure Modes in Internal Platform Programs

Failure Mode 1: Tool-first, product-last

Buying a portal or an orchestrator expecting it to solve platform problems without a product owner, a target developer segment, and a measurable adoption goal is the most common failure mode across published post-mortems and community discussions. The failure signal is a technically successful deployment with single-digit weekly active use.

Failure Mode 2: No platform product manager

The Puppet 2024 State of DevOps report found that 52 percent of respondents named a platform product manager as central to platform team success. Platform teams staffed only with engineers tend to over-invest in capabilities that engineers find interesting and under-invest in the developer experience that drives adoption.

Failure Mode 3: Forced adoption of immature golden paths

Mandating a paved path that does not yet handle common exceptions pushes teams into shadow infrastructure. The failure signal is a growing catalog of undocumented service configurations living outside the platform, usually visible in cloud billing before it is visible in the platform's own metrics.

Failure Mode 4: Wrong abstraction layer for the audience

A platform that models workloads at too high a level frustrates senior engineers who need escape hatches, while a platform that exposes too much infrastructure detail fails to help the junior engineers it was justified to serve. The failure signal is that neither developer segment reports the platform as their preferred deployment path 6 months after launch.

Failure Mode 5: Under-resourced platform team on Backstage

Self-hosted Backstage requires 2 to 4 dedicated engineers to reach a production state and continues to require plugin and upgrade work indefinitely. Teams that assume Backstage is free because the framework is open source consistently discover that the total cost of ownership over 3 years, once engineering time is included, matches or exceeds the cost of a commercial portal.

Failure Mode 6: Excluding non-developer stakeholders

Security, FinOps, and service owners have direct requirements against the platform: policy enforcement, cost attribution, and on-call metadata. Excluding them from requirements early tends to produce a portal that satisfies developer ergonomics but fails governance reviews at rollout time.

12Sizing and Adoption Heuristics

These heuristics are directional, drawn from published benchmarks, and should be adjusted for organizational context.

• Under 50 engineers: skip a formal internal developer platform; document a small set of golden path templates instead.
• 50 to 100 engineers: consider a bundled platform-as-a-service alternative such as Northflank, Qovery, or Encore before building a platform team.
• 100 to 300 engineers: commercial portals or managed Backstage typically pay back within two quarters if a platform product owner is in place.
• 300 to 1,000 engineers: managed Backstage or a commercial portal remains the default; self-hosted Backstage is defensible only when a platform team of 3 or more engineers is already funded.
• 1,000 or more engineers: self-hosted Backstage becomes defensible when unusual workflow requirements exceed what commercial portals model, and when 3 to 12 platform engineers can be committed indefinitely.
• Adoption target: weekly active platform users as a percentage of eligible engineers is a better health metric than portal page views or catalog entry counts.

13Vendor Reference Table

This table is inventory, not a ranking. Vendor mentions follow StackAuthority's canonical entity policy and are included based on public positioning and community traction rather than paid placement.

Public source references: Backstage, Roadie, Port, Cortex, OpsLevel, Configure8, Rely.io, Humanitec, Kratix, Score, Northflank, Qovery, Encore.

14Evidence Package to Request From Every Vendor

Ask for evidence in a comparable format so internal review remains objective. Vendor decks are not evidence.

• one reference customer at your scale with a named platform lead who can be contacted
• one paved path implementation artifact showing how a template is created, versioned, and updated in place
• one integration example against your existing CI, GitOps, and cloud provider
• one scorecard or standards check example with a documented gate against CI or CD
• one 3-year total cost of ownership model including seat cost, platform team time, and runtime cost
• one security package including SOC 2 report, secret handling documentation, and SSO and audit log details

Weak or generic artifacts in this package are a stronger negative signal than a weak sales conversation.

15Interview Script: High-Signal Questions

Fit and integration questions

1. Show how a developer creates a new service in your portal end to end, including provisioning, without leaving the interface.
2. Show a reference customer that runs on the same CI, GitOps, and cloud stack as ours.
3. Show what breaks when the developer needs an exception the paved path does not model.

Governance and standards questions

1. Show how a scorecard is created, reviewed, and gated in CI or CD.
2. Show how ownership is modeled across services, teams, and systems, and how it stays current.
3. Show how a security team reviews and approves changes to a golden path template.

Adoption and product questions

1. Show three reference customers at our scale with their weekly active user percentage.
2. Show one case where a customer removed a paved path because adoption stalled, and what changed after.
3. Show how a customer with a platform product manager compared with one without.

Vendors that decline to answer product and adoption questions in favor of feature demonstrations are usually selling a tool, not a platform capability, and the difference tends to be felt after purchase.

16Pilot Structure Before Full Contract

A narrow, measurable pilot produces stronger decision signal than a long proposal cycle.

Recommended pilot scope:

• 2 to 3 product teams with different service profiles
• one paved path implemented end to end, including provisioning and observability
• one scorecard reported and gated in CI or CD for at least one service
• one integration against your existing GitOps or CI system

Pilot decision criteria:

• weekly active use by pilot teams reaches at least 60 percent of eligible engineers
• paved path can be updated in place without regressing pilot services
• exception handling has a documented, non-manual path
• platform team can run the tool with support at the level offered in the contract

If pilot criteria are met, expand with phased scaling language. If not, revise the layer choice or the vendor choice before expanding.

17Due Diligence Questions by Stakeholder

For the CTO and VP Engineering

• What operating cadence changes after this platform is in production?
• What adoption metric will define success in 6 and 12 months?
• What is the escape path if the vendor is acquired or discontinues the product?

For the Head of Platform

• What developer segment is this platform for, and which segments will not use it?
• What paved paths ship on day one, and which are deferred?
• What is the platform team headcount plan through the first 12 months of operation?

For Security and Compliance

• What identity, secret, and audit controls does the platform enforce by default?
• What evidence is retained per deployment and per configuration change?
• How does the platform integrate with existing policy enforcement?

For Service Owners

• What changes for a service team on day one, and what changes over the first quarter?
• Where are the escape hatches when the paved path does not fit a legitimate case?
• How is ownership metadata kept current without manual effort from service teams?

Weak answers from one stakeholder group predict rollout friction even when technical planning is strong.

18Procurement and Contracting Guidance

The highest-value contract terms are usually operational, not financial.

Recommended contract elements

• adoption milestone commitments with a defined weekly active user target
• named technical account manager with minimum continuity period
• documented upgrade path and support commitments for major version changes
• data portability commitment covering catalog entries, ownership, and scorecards
• exit clause with a defined data export format if adoption or renewal fails

Avoid contracts that price only on seat count without any operating commitment from the vendor. Seat-only contracts push all rollout risk onto the buyer.

1990-Day Success Markers

A healthy first 90 days usually includes:

• a named platform product manager with a written charter
• one paved path live and used by at least two product teams
• one scorecard reported and one gate wired into CI or CD
• adoption reporting available to platform leadership on a weekly basis
• an exception process documented and used at least once without escalation

If these markers are missing, assess whether the engagement is missing product ownership, not tooling.

20Common Evaluation Mistakes and How to Avoid Them

Mistake 1: Deciding on framework capability before deciding on the layer

Comparing Backstage to Port to Humanitec is a category error because they address different layers. First decide whether the primary pain is catalog, provisioning, or a bundled stack. Then compare vendors within the layer.

Mistake 2: Treating Backstage as free

The Backstage framework is open source; the platform team required to run it in production is not. Include 3-year platform team cost, plugin maintenance, and framework upgrade cost in any Backstage total cost of ownership model.

Mistake 3: Buying a portal without a product manager

Portals without a platform product manager consistently underperform their adoption targets. Fund the product management role before signing a portal contract.

Mistake 4: Excluding security and FinOps from requirements

Retrofitting policy enforcement and cost attribution into a portal after adoption starts is significantly harder than including them in the initial data model. Include both groups in evaluation from the start.

Mistake 5: Skipping the pilot

A 6 to 8 week pilot with 2 to 3 product teams gives stronger signal than any vendor reference call. Skip the pilot only when a comparable-scale reference customer with a nearly identical stack is available for direct comparison.

21Architecture Diagram: Platform Product Loop

[Target developer segment + paved-path scope]
              |
              v
   [Portal or PaaS interface]
              |
              v
   [Workload spec or template]
              |
              v
   [Orchestrator or CI pipeline]
              |
              v
   [Cloud, Kubernetes, data services]
              |
              v
   [Scorecards, ownership, audit surface]
              |
              v
   [Adoption metrics + exception review]
              |
              v
   [Roadmap update for next paved path]

The loop is continuous. A platform program that treats the initial rollout as the finish line typically loses adoption to shadow infrastructure within a year.

22External References

• CNCF Platforms White Paper
• CNCF Platform Engineering Maturity Model
• Puppet 2024 State of DevOps Report
• Team Topologies key concepts
• Thoughtworks Technology Radar entry for Port
• platformengineering.org guidance on failure modes

23Decision Questions for Leadership

How do we know we need an internal developer platform rather than better templates

If provisioning a new service takes more than two working days, if deployment configuration is copy-pasted across services, and if on-call incidents recurrently trace to configuration inconsistency, the case for a platform is strong. If none of those are true and the organization is under 100 engineers, better templates on top of existing CI and infrastructure-as-code are usually the right answer.

Should we start with a portal or with a workload orchestrator

Start with the layer that addresses the loudest current pain. If service sprawl, ownership, and standards are the pain, start with a portal. If provisioning ticket queues and environment inconsistency are the pain, start with an orchestrator. Combining both in one initial rollout usually extends time to first value beyond the point where leadership retains patience.

When is self-hosted Backstage the right call

When the organization has more than 1,000 engineers, a funded platform team of 3 or more engineers, unusual workflow requirements that commercial portals do not model, and a runway of at least 6 months before adoption metrics are evaluated. Below any of those thresholds, managed Backstage or a commercial portal typically produces better outcomes at lower total cost of ownership.

How do we prevent this from becoming another shelved platform

Fund a platform product manager, define the target developer segment, ship one paved path end to end before adding a second, and measure weekly active use as the primary adoption metric. Every platform program that has recovered from an early stall has done some version of these four things.

24Decision Evidence Checklist

Use this checklist before contract approval:

• named platform product owner with a written charter and adoption target
• defined target developer segment and the paved paths that segment needs first
• layer decision (portal, orchestrator, bundled PaaS) with written rationale
• vendor comparison across at least two options within the chosen layer
• pilot plan with 2 to 3 teams and measurable exit criteria
• 3-year total cost of ownership including platform team FTE cost
• security, FinOps, and service owner sign-off on the data model and policy surface
• exit and portability terms in the contract

25Frequently Asked Questions

What is an internal developer platform

An internal developer platform is a product a platform team builds so product engineers can build, deploy, and operate services on the organization's chosen infrastructure without becoming infrastructure specialists. The CNCF Platforms White Paper defines a platform as a coherent collection of capabilities defined and presented according to the needs of its users; a catalog of Helm charts with documentation does not meet that bar.

When should an organization adopt an internal developer platform

Above roughly 100 product engineers, when provisioning a new service takes more than two working days, when deployment configuration is copy-pasted across services, and when on-call incidents recurrently trace to configuration inconsistency. Below 50 engineers, a small set of documented golden path templates on top of existing CI and infrastructure-as-code usually produces better outcomes at lower total cost of ownership.

Is Backstage worth the investment

Self-hosted Backstage is defensible at roughly 1,000 or more engineers with 3 to 12 dedicated platform engineers who can write and maintain React and TypeScript plugins. Below that scale, managed Backstage from Roadie or a commercial portal such as Port, Cortex, or OpsLevel typically reaches production 5 to 10 times faster at lower 3-year total cost of ownership.

Backstage vs Port: which one should we choose

Backstage is the right choice when the organization has unusual workflow requirements that commercial portals do not model, a runway of at least 6 months, and a funded platform team. Port is the right choice when the goal is a portal in production within 2 to 6 weeks, the primary pain is catalog and standards rather than a specialized workflow, and the platform team is small. Choosing between them without first deciding the layer (portal versus workload orchestrator) is a category error.

What is the difference between a developer portal and a workload orchestrator

A developer portal is the interface layer: catalog, ownership, scorecards, golden path templates. A workload orchestrator is the delivery layer: it translates a developer-authored workload specification into provisioned infrastructure across environments. Backstage, Port, Cortex, and OpsLevel are portals. Humanitec, Kratix, and the Score specification address the orchestrator layer. Some organizations need one, some need both, and buying inside the wrong layer is a common failure mode.

Why do internal platform initiatives fail

Roughly 70 percent of platform initiatives struggle with adoption or expected value, most often because they are run as tool projects rather than as products with named owners, defined users, and measurable adoption goals. The Puppet 2024 State of DevOps report identifies the absence of a platform product manager as a primary predictor of platform team underperformance.

What adoption metric should platform teams report

Weekly active platform users as a percentage of eligible engineers. Page views, catalog entry counts, and template runs are activity indicators, not adoption indicators. Spotify reports approximately 99 percent internal Backstage adoption; external adopters typically fall in the 10 to 30 percent range, and the delta almost always tracks whether the platform is run as a product with an owner and a target segment.

How much does an internal developer platform cost

The dominant cost is platform team FTEs, not tooling. A self-hosted Backstage deployment requires 3 to 12 engineers indefinitely. Commercial portals typically price per developer per month with seat minimums, and total cost of ownership over 3 years is usually competitive with or lower than self-hosted Backstage once engineering time is included. Any procurement model that compares only seat prices without including platform team cost will produce a misleading answer.

26Limitations

This guide improves platform layer selection and vendor evaluation quality. It does not replace internal architecture review, legal review, or environment-specific risk decisions. Final selection should include direct reference checks with comparable-scale customers and a scoped pilot before broad rollout. Adoption benchmarks cited from third-party sources are directional and vary substantially across organizations.

27Related Reading

• Leading Platform Engineering Partners for Kubernetes Upgrade and Cluster Lifecycle Programs
• Kubernetes Upgrade Program Buying Guide for CTOs
• Cloud Cost Allocation for Platform Teams Buying Guide
• Methodology

Author: Mira Voss Reviewed by: StackAuthority Editorial Team Review cadence: Quarterly (90-day refresh cycle)