What is the ROI of Spotify’s Backstage internal developer portal?

January 28, 2025

What is the ROI of Spotify’s Backstage internal developer portal?

There is a strong appeal for engineers to use Spotify’s Backstage to build an internal developer portal; you can theoretically build what you’d like to fit your organization's needs with unlimited customization. However, this is a common misconception, and reality often falls short of these expectations.

This misconception is fuelled by the fact that Backstage is open source, which many developers favor both because it is a community-driven project and because, in their eyes, it is easier to get sign-off from their reporting managers — be they the VP of engineering or someone else — to use open source software instead of buying new software. The logic is that it doesn’t cost as much as a commercial alternative and therefore the decision won’t be scrutinized as much as commercial internal developer portals. 

There is also a competing belief that all it takes to make Backstage operational is a small team of one or two engineers can work on the project, while others in the team can work on other initiatives. This is another misunderstanding that Gartner has highlighted in its recent research. Gartner said that a custom internal developer portal like Backstage requires more time, effort and development skills than many platform engineering leaders expect. The research company also notes that the mistaken belief that Backstage is a ready-to-use portal leads to disillusionment among the developers who choose it, which sometimes leads them to either abandon the project when additional work is required or look for a Backstage replacement. 

The reality is that there are complexities with Backstage that may not become apparent until an engineering team has already invested heavily — both in terms of time and in terms of people. These complexities include the fact that every feature of a Backstage-built portal is the result of developers creating custom backend and frontend plugins, which are a resource drain. 

The true costs and feature limitations of Backstage may only become apparent after six months or a year. By that time, the resources used and the good will from leaders and others in the organization will leave Backstage champions with a big decision to make:

  1. Stick with Backstage
    You could carry on with the Backstage project, as it’s heavily customized, you’ve already put in a lot of effort and resources into it, and it may provide you with some benefits in the long run. But, this means you will have to invest even more in terms of resources (people and time). You may not get all of the use cases and features you were initially seeking and therefore you may fail to get developers adopting the platform. You will also have to factor in the cost of delays; if you’re not getting a return-on-investment on Backstage for months or years, you’re effectively tying up resources in a portal that fails to deliver timely value, risking opportunity costs and potential inefficiencies. This will subsequently impact engineering KPIs and business outcomes.

OR

  1. Pivot and find a new solution
    Look for alternative solutions. There is potential to build an internal developer portal faster, with more of the features and use cases you’d like, without sacrificing the flexibility of the portal. As a result, there will be a quicker and larger return on investment, and therefore a reduction in the cost of delay. An alternative portal is more likely to align with engineering KPIs and business outcomes. However, you would have to write-off the costs associated with Backstage up until this date. 

This decision is an unenviable position to be in for whoever is leading a Backstage initiative. 

Book a demo right now to check out Port's developer portal yourself

What Backstage really costs 

There are two key things to factor in with costs: engineering resources and time-to-value. 

Engineering resources

Gartner says organizations should expect to dedicate up to ten engineers on Backstage for several years, but this is a conservative estimate, with many organizations dedicating far more than this. Using an example from an engineering team that Port has spoken to directly, an organization with 300 developers requires between 7 and 15 engineers to be able to extract value from Backstage — and even then, the value extracted from the resulting portal pales in significance when compared to alternative portals. Those organizations that believe they can get a positive ROI from Backstage with just one or two engineers have unrealistic expectations.

Here is a deeper dive into why so many engineering resources are needed:

  • On-premise implementation and maintenance:  Two of the key technical disadvantages of Backstage are that it has a fixed data model which means you can’t represent every type of entity in your software catalog, and that ingesting data requires some sort of manual work with YAML files, creating more work for maintainability. In general, on-premise deployments require more work to set up, maintain and scale, and they include complex networking. All of this lends itself towards an engineer that has deep knowledge of DevOps tools.


          Requirement: A platform engineer/DevOps engineer

  • Plugin architecture: While there are over 100 plugins in the Backstage marketplace, they’re often very basic and dedicated to a single task. For instance, a Snyk plugin will be focused on tracking Snyk vulnerabilities, while a GCP plugin will only list GCP assets; what’s worse is these standalone plugins do not offer cross-integration views. That means, for instance, if you want to see which vulnerabilities reside on a service that is currently in production, you have to develop a new plugin. 

    As a result, developers aren’t able to get answers to the questions they may have — which is one of the primary reasons for using a portal, and is the foundation for many use cases such as incident management, cloud cost optimization, and infrastructure management. To develop these customized plugins requires both front-end skills (including familiarity with the React framework) and back-end or DevOps skills. Over time, the number of engineers required and the time to build the plugins will increase, as will the upkeep of version control and quality, for which the Backstage framework has no in-built capability to track.

    Requirements: 2 front-end engineers that understand React and 2 full-stack engineers to work on the back-end
  • Support for self-service actions: As Backstage Software Templates are designed to perform self-service actions, Backstage users are limited in what they are able to achieve, with a primary focus on scaffolding new services. Actions such as deploying services, rolling back changes, triggering incidents, creating cloud resources, toggling feature flags, managing secrets, obtaining temporary database permissions, and setting up development environments are challenging to execute directly in Backstage due to its lack of built-in support for these functionalities.

    Existing CI/CD pipelines already have actions that allow for quick and reliable execution of day-2 operations, but using Backstage would require them to stop as it offers little in the way of direct support for such actions. As a result, an engineer would need to focus on adding another layer within Backstage to accommodate such actions, even though these could introduce errors and unnecessary dependencies.

    Requirement: Another DevOps & cloud engineer
  • Updating code due to updates and breaking changes: Backstage users regularly complain about breaking changes that require them to update their code for their various plugins, creating even more work. These breaking changes can stall the portal project for weeks due to the workload it creates. 

    Requirement: DevOps engineer
  • Aligning the project with objectives: With so many objectives, tasks and motives for the project, there needs to be a dedicated product or project manager that can ensure that the team maintains its overarching goal and does not veer off-course. Without a manager, teams may spend up to a year developing their portal without seeing tangible results.

    A platform-as-a-product mindset is crucial to platform engineering success, and a manager should embody this by ensuring that the portal they’re building is catered to those that will use it, by treating them as customers. They should tell the team what they need to work on, explain upcoming tasks and ensure deadlines are met. 

    Requirement: Project manager/product manager

Total requirement: 8 full-time engineers. This is the bare minimum for a Backstage project.

The vendor-agnostic online community www.internaldeveloperplatform.org estimates Backstage’s true cost of ownership at approximately $150,000 per 20 developers. While it may appear free initially, the significant hidden costs often lead teams to explore more efficient commercial alternatives.

Watch Port live coding videos - setting up an internal developer portal & platform

Time to value

The work begins after your engineering resources are aligned. Even if you have the required engineering resources, it still takes up to 12 months to get Backstage to a state where the software catalog and self-service actions are providing enough value for engineers to regularly use the portal because Backstage begins as a blank canvas. 

Backstage overall costs

For an enterprise of 300 developers building an in-house portal on top of Backstage, the costs break down as follows:

Initial build costs

  • Development resources: 7 FTEs (1 PM, 2 front-end engineers, 2 full-stack engineers, 2 DevOps engineers) at ~$150,000/year each = $1,050,000/year.
  • Time to build: 12 months.
  • Total initial investment: $1,050,000.

Ongoing maintenance and development

  • Ongoing development: 4 FTEs at $600,000/year.
  • Dedicated maintenance team: 2 FTEs for platform management and handling Backstage release updates = $300,000/year.
  • Infrastructure costs: $50,000/year.
  • Total yearly maintenance: $1,100,000/year.

Total 3-year cost with Backstage

  • Initial build: $1,050,000.
  • Maintenance (2 years): $2,200,000.
  • Total cost over 3 years: $3,250,000.

Comparing Backstage vs Port

Total cost of ownership: Backstage vs. Port

Backstage and Port both enable you to build an internal developer portal, but a few key differences in their design amount to major differences in their total cost of ownership and potential.

Design element Backstage Port
Data model design Schema flexibility through custom annotations, typically driven through GitOps, in each catalog-info.yaml file Flexible data model, but centralized definition — however the data is integrated, it is normalized and validated effectively
Back-end customization Custom plugins, writing code for integrating data sources, joining data, automation and self-service. Complexity of managing plugin state that might not fit in the catalog A big library of integrations and a simple way to connect to organizations' existing pipelines for custom self-service and workflow automation extensibility
Front-end customization style Custom plugins, writing code for every new view, table, graph Pre-made front-end widgets that plug into data sources
Development lifecycle Writing code, building, releasing Configuration-driven, through click-ops, APIs, or Terraform provider
RBAC Work it out yourself Flexible RBAC, tight controls across self-service, catalog for all personas
Auditability Work it out yourself and implement across custom plugins Audits are baked-in by default

Unlike Backstage, Port is an open commercial platform with no-code and low-code abilities that does the heavy lifting of the core efforts for you:

  • The software catalog is SaaS-hosted, which means that Port takes care of scaling, maintaining, updating and adding new features automatically
  • Exporters can be SaaS or on-premise, with no complex requirements
  • Integrations are maintained by Port, updating vendors’ APIs as they evolve. These integrations are secure, on-premise exporters that are maintained and vetted. They are also community-driven through Port’s Ocean framework, meaning no coding is required. You can also integrate with the tools you’re already using. 
  • No plugin development: Adding a new integration enriches the catalog and the new integration is part of a unified data model. This means that organizations can get the context they need to answer questions like “Do I have a Snyk vulnerability in production?” and don’t require the resources to build customized plugins.
  • Expanding the data model to custom integrations is easy, does not require front-end and integrates smoothly into the rest of the integrations.
  • The flexible data model enables changes in the entity types and customization of the metadata model to evolve as the portal requirements change — meaning you can cover current and future use cases, and accommodate changes in the organization as they arise. 

Thanks to these features, Port offers a more streamlined and cost-efficient approach compared to Backstage. While Port may have an upfront cost, it eliminates the substantial front-end investment and significantly reduces the number of engineers needed to build, maintain, and operate the portal, which delivers greater value and efficiency from the start.

Open a free Port account. No credit card required

Let’s start

Port vs. Backstage ROI

Aside from identifying the upfront and ongoing costs associated with the portals, engineering teams will want to compare the overall return-on-investment. 

Aspect Backstage Port
Initial costs Low initial costs: Open-source with minimal upfront investment. Predictable costs: Follows a subscription-based pricing model.
Time to ROI Delayed ROI: Custom development can take time to deliver value. Fast ROI: Offers potential for returns within the first year.
Long-term costs High long-term costs: Maintenance, plugin development, and updates require ongoing effort just for the portal, outside of regular development costs. Low long-term costs as Port takes care of scaling, maintaining and updating the portal itself.
Workload Work and specialist skill sets required for self-service support and overall upkeep. Automation-first: Designed to reduce DevOps workload with built-in workflows.
Implementation The implementation can take up to 12 months before launching. Enterprise-ready: Provides quick implementation with pre-built solutions.

As a result, Port’s time-to-value is faster and ROI is higher than Backstage’s as shown in the below graphic:

Port requires upfront investment, but it provides a faster and more significant ROI. As the catalog more quickly becomes a source-of-truth for engineers and as self-service actions are more readily available and easy to create and support, Port’s ROI climbs significantly from the five-month mark. This offers organizations better predictability and earlier benefits. Port’s ROI curve is steep because of the flexibility of the portal and the number of use cases that developers are likely to benefit from.

Meanwhile, due to Backstage’s complexity and requirement for additional resources, it can take up to two years for true value to be shown. This complexity becomes more apparent as the months go on, and though it begins to recover over time, the curve remains shallow, indicating a slower realization of value. This is likely due to ongoing maintenance and developer efforts. Backstage’s ROI curve’s trajectory is also not as steep. 

If you’re not done analyzing internal developer portals, check out this list of the top Backstage alternatives or compare Port vs. Backstage here. If you’re heavily invested in Backstage and don’t want to look for an alternative solution, but want a way of addressing issues with the plugin architecture, apply to join our beta for Port’s Backstage plugin.

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}
{{cta_4}}
{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

{{cta-demo-baner}}
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start