Spotify & the Birth of Backstage

This is the case that gave the whole industry two of its favourite words: golden path and Backstage. It is a real, named company's story, and this page sticks to what Spotify's own engineers have said about it in public — engineering-blog posts, Backstage's own documentation, and on-the-record press interviews. No invented metrics, no filled-in gaps. Where the public record runs out, this page says so rather than guessing.

The starting situation: hypergrowth turns autonomy into fragmentation

☺ Like you're 10: When a school gets huge fast, "everyone does their own thing" stops being freedom and starts being chaos — nobody can find anything.

"Rumour-driven development"

Spotify's engineering organisation is famous for the "Spotify model" of autonomous squads and tribes, popularised around 2012 in Henrik Kniberg's widely shared write-up of Spotify's culture. Whatever you think of that model as an org chart — it's frequently cited today as more aspirational marketing than an accurate map of how Spotify actually ran engineering — the underlying fact this case study cares about is real and well documented: squad autonomy at scale produced serious tooling fragmentation. As Spotify's own engineering blog put it in a 2020 post, independent teams built independent point solutions without knowing similar ones existed elsewhere, and the only way to learn how to do something was to ask a colleague — what the post itself named "rumour-driven development."

System Z: the first fix

By 2014, Spotify had grown past 100 engineers who were spinning up new microservices on a weekly basis, according to an account of Backstage's history summarised in Gergely Orosz's Pragmatic Engineer newsletter (itself drawing on Spotify's own retrospective). Services multiplied faster than anyone could track them: nobody had a reliable answer to "what exists," "who owns it," or "is this actually running in production." A platform team's response was a small internal tool they called System Z — a registry where a team could register a service along with its code link, its owning team, and its product owner.

The Golden Path: origin, and what it means as a practice, not a tool

☺ Like you're 10: A golden path didn't start as a fancy piece of software — it started as one really good instruction sheet a few engineers wrote in a single week.

A Hack Week tutorial, not a platform roadmap item

This is the detail most retellings skip, and it matters: the Golden Path did not begin as a platform feature. According to Spotify's own 2020 engineering-blog post, "How We Use Golden Paths to Solve Fragmentation in Our Software Ecosystem," the first Golden Path tutorial was built during a company Hack Week, roughly six years before that post was written — put a handful of senior backend engineers in a room for a week, and what came out was a single, opinionated, step-by-step tutorial for "the recommended way of using our services." It worked well enough that Spotify's Platform Developer Experience (PDX) tribe formalised the pattern and extended it across other disciplines.

The blog post defines a Golden Path plainly: "the opinionated and supported path to build something" — a backend service, a website, a data pipeline. By the time that post was written, Spotify had one Golden Path tutorial per discipline — backend, client, data engineering, data science, machine learning, web, and audio processing — each built as a written, step-by-step tutorial (using the same TechDocs mechanism you can read about on the Backstage page) and then surfaced inside Backstage itself, so the "how-to" documentation lives right next to the catalog entry for the thing it's about.

Optional, not mandatory

Crucially, Spotify made the path optional, never mandatory — the post is explicit that "the idea behind having Golden Paths is not to limit or stifle engineers." A team can still build something bespoke; they simply don't get the same support, documentation, or fast lane if they do. That non-coercive design is exactly the mechanic covered in more depth on Platform as a Product & Golden Paths — a path people are free to leave is the only kind of path you can honestly measure the popularity of.

Architecture and technology decisions: from a registry to a portal

☺ Like you're 10: The noticeboard started as a simple list, then grew buttons, then grew so many buttons that they had to rebuild it from scratch.

The 2017 rewrite

System Z's scope grew organically. Per Backstage's own "Spotify Story" background documentation, once engineers were already visiting System Z daily to look up service ownership, the platform team noticed it was also the natural place to bolt on UIs for developer-infrastructure tools that had previously only existed as CLIs. Relationships between services got modelled too — which service depended on which, and which services belonged together as one product. By 2017, System Z's organic feature growth had outpaced its original design, and Spotify undertook a complete rewrite. That rewrite is the tool that would eventually be named Backstage.

Two concepts: the catalog and the templates

Two concepts came out of that rewrite as Backstage's structural core, both explored in full depth on the dedicated Backstage page — this case study only needs their shape:

A minimal software-catalog entry looks like this — the same shape whether you're Spotify in 2017 or a reader trying this today (see Backstage for the full entity-kind reference):

# catalog-info.yaml — lives at the root of the service's own repo
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: recommendations
  description: Generates the Discover Weekly candidate set.
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: group:default/personalization-team
  system: discovery

Plugins: extending without re-centralising

Backstage's plugin architecture followed the same growth pattern as System Z did before it: rather than one team owning every integration, other teams could write a plugin against a stable API and have it appear as a tab on the catalog entity page — Kubernetes status, on-call, CI results, cost. The platform team keeps owning the core (catalog, scaffolder, TechDocs); everyone else extends it. That division of labour is exactly what let the tool keep scaling past what any one team could build alone.

Organisational choices: who owns the path, and how that changed

☺ Like you're 10: At first, one person wrote every instruction sheet. That became too much for one person, so lots of teams started writing their own — which brought a new problem.

From one writer to distributed ownership

The organisational story here is honestly reported, including its own unsolved edge. Spotify's 2020 Golden Paths post describes the ownership model evolving in two stages. Initially, a single technical writer owned each Golden Path tutorial — a workable model at small scale, since one person could keep one tutorial coherent and current. As the number of paths grew across seven-plus disciplines, that didn't scale, and ownership shifted to being distributed across multiple teams per discipline. Spotify's own post is candid that this created a new coordination problem it was still working through at time of writing: many owners can mean many slightly different opinions about what "the" backend Golden Path should even be.

Treating the path as a product, not a project

The broader organisational lesson is one this course returns to repeatedly on Platform as a Product & Golden Paths: the PDX tribe treated the Golden Paths as a product with real owners and a mandate to keep them current, not a one-off documentation project that ships and then rots. The tutorials became, in Spotify's own words, "our most read and most used technical documentation" and are folded directly into new-engineer onboarding in their first two weeks — which only stays true if someone keeps them alive.

Why Spotify open-sourced it — and then gave it to the CNCF

☺ Like you're 10: They'd already been burned once by building their own version of something everyone else eventually standardised on — so this time, they got ahead of it.

The stated reasons

Spotify open-sourced Backstage on March 16, 2020 — by its own account, the company's first major open-source infrastructure release — and donated it to the Cloud Native Computing Foundation later that year; the CNCF accepted it as a Sandbox project on September 8, 2020, and it graduated to the Incubating maturity level on March 15, 2022. The stated reasoning, on the record from more than one source, is more interesting than "we like open source":

• A scar from Helios. In a 2022 interview with TechCrunch, Spotify's head of technology and platforms, Tyson Singer, described the company's earlier homegrown container-orchestration system, Helios, being overtaken by Kubernetes: "it was painful and expensive for us to do" to migrate off it once Kubernetes won the industry. Singer's stated conclusion for Backstage was blunt: "we do not want to have to replace that." Rather than risk a competitor's developer portal becoming the de facto standard and forcing a costly migration later, Spotify chose to make Backstage the standard first.
• Sharing productivity gains. Backstage's own non-technical FAQ states the internal reasoning plainly: having watched how much the tool improved developer experience internally, the team "wanted to share those gains" — reasoning that if a portal could bring order to an engineering organisation as sprawling as Spotify's, it stood a good chance of helping others too.
• The community pays it forward. Backstage's history since 2020 backs up the bet. Within roughly six months of the open-source release, over 130 external contributors had submitted changes — about 40% of pull requests came from outside Spotify — and early adopters included American Airlines, Expedia and Netflix. A frequently retold example: a dark-mode feature that Spotify's own team hadn't gotten around to prioritising was built and merged by an outside contributor within 24 hours of being requested.

Notice that this is the mirror image of the Golden Path story: the Golden Path was Spotify importing discipline into a fragmented internal ecosystem, while open-sourcing Backstage was Spotify exporting that discipline so the wider industry wouldn't fragment around competing portals the way container orchestration once did.

The public timeline

What changed: the numbers Spotify has actually published

☺ Like you're 10: Faster new-hire ramp-up inside Spotify, and thousands of other companies borrowing the same noticeboard.

Public, attributable figures are thinner here than the qualitative story, and this page only uses the ones traceable to a named source. The Pragmatic Engineer newsletter's account of Backstage's history, drawing on Spotify's own retrospective, cites a 55% decrease in onboarding time for new engineers and adoption across 280 internal engineering teams by 2020. Spotify's own five-year retrospective, published on its engineering blog in 2025, states that Backstage's Golden Path tutorials became the company's most-read and most-used technical documentation, and that roughly 700 Spotify R&D squads now rely on the tool to ship daily. The same 2025 post reports that more than 3,000 companies outside Spotify had adopted Backstage to build their own internal developer portals — a figure that has grown from the "over 130 external contributors, ~40% of PRs from outside Spotify" reported within roughly six months of the 2020 open-source release.

What to steal for your own platform

☺ Like you're 10: You don't need Spotify's size to copy their trick — write the instruction sheet before you write the software.

• Start with the tutorial, not the tool. Spotify's own most successful Golden Path began as a written, human-followable tutorial produced in a single week, long before any scaffolder existed. Write the "opinionated and supported path to build a service" as documentation first; automate it once you know it's actually the right path. This is the exact discipline explored on Platform as a Product & Golden Paths.
• Make the path optional, and mean it. A path nobody is forced onto, but that people choose because it's genuinely the fastest way to get something done, is the only kind of path whose popularity actually tells you something. A mandated path just tells you compliance is enforced.
• Put the catalog metadata next to the code, not in a separate wiki. System Z's original registry decayed the moment ownership data lived somewhere other than the repo itself. A catalog-info.yaml that ships in the same pull request as the code it describes is far more likely to stay true than a spreadsheet someone updates "when they remember."
• Name an owner for the path, and expect ownership to need to evolve. Spotify's shift from one technical writer to distributed team ownership, and the coordination friction that followed, is a preview of a growing pain you'll likely hit too — plan for it rather than being surprised by it.
• If you build something genuinely reusable, consider giving it away before someone else's version becomes the standard. Spotify's Helios experience is the sharpest version of this lesson: owning a bespoke internal tool that the industry eventually standardises around something else is expensive to unwind. Open-sourcing early is itself a hedge.

Honest caveats: what doesn't transfer

☺ Like you're 10: A story built for a company Spotify's size doesn't automatically fit a company with twenty engineers.

• Scale changes the calculus entirely. Spotify built System Z once it had passed 100 engineers spinning up new services weekly. A twenty-engineer startup with a handful of services has a fragmentation problem that a good README and a shared repo template solves — see the "build, buy, or skip" guidance on Backstage before assuming you need a portal at all.
• The "Spotify model" of squads and tribes is not the same claim as the Golden Path story. The squad/tribe org model is widely — and, per several retrospective critiques, fairly — accused of being oversold by consultants relative to how rigidly Spotify itself actually applied it. This case study treats the org model only as context for why fragmentation happened, not as a template to copy; don't let one blur into an endorsement of the other.
• Open-sourcing your internal tool is a strategic bet, not a checklist item. Spotify's decision was backed by a specific scar (Helios), a specific ambition (industry standard), and a company with the engineering capacity to maintain a public open-source project indefinitely. Open-sourcing an internal tool you can't sustain is a reputational risk, not a gift.
• You will not get Spotify's own audited numbers, because they don't exist publicly. As covered above, the 55%-onboarding-time figure and team-adoption counts are self-reported without published methodology. Treat them as a "this clearly worked for them," not as a specific target you should expect to replicate exactly.
• A portal doesn't replace the platform behind it. Backstage itself only writes to Git and reads from everything else — the actual paved road is the GitOps reconciliation, the platform APIs, and the policy Backstage's buttons point at. Spotify built years of underlying platform capability before the portal made it discoverable; don't expect a portal alone to fix a platform that isn't there yet.

Where this connects in the course

☺ Like you're 10: This one story touches three different lessons — read them next in whichever order matches what you're building.

This case is really three lessons wearing one company's name tag. The mindset — treat the platform as a product, and a golden path as something developers choose rather than something forced on them — is Platform as a Product & Golden Paths. The mechanics — Software Catalog, Software Templates, TechDocs, and the gotchas of actually operating a Backstage instance — are the full Backstage deep dive. And how a catalog and a scaffolder compose with Crossplane, GitOps and policy into one end-to-end paved road is Self-Service & Developer Portals. For the other companies whose public stories sit alongside this one, return to the case studies hub.