Golden paths cost: authoring, maintaining, and sunsetting

What golden paths are for

A golden path is an opinionated, paved route through the platform for a common task. The Team Topologies framework popularised the term; Spotify's engineering blog made it concrete with examples; the broader platform-engineering community adopted it as the canonical name for the most valuable thing a platform team does.

The canonical golden path is "create a new service of type X". The platform team has decided what a healthy service of type X looks like: which language and framework, which deployment target, which CI/CD pipeline configuration, which observability defaults, which secrets-management pattern, which catalogue metadata, which on-call expectations. The scaffolder takes one input from the product engineer (a service name and a few configuration choices) and produces all of the above as a working unit ready to deploy.

Product engineers who follow the golden path get a working service in production within a few hours with no platform-engineering ticket. Engineers who deviate from the golden path can still ship, but they take on the cost of integrating each platform capability themselves: wiring CI/CD, configuring observability, registering in the catalogue, setting up secrets, ensuring the service meets the organisation's standards.

Golden paths are the most concrete expression of platform value because the time saved is directly measurable: hours per service in the case of a one-off scaffold, person-weeks per quarter at the aggregate organisation level.

The authoring cost

A first-time golden path costs 4 to 8 engineer-weeks to author, or $40k to $80k of loaded platform-engineer cost. The work breaks down:

• Design and scoping (1 to 2 weeks). What should the template look like? What language and framework? What deployment target? What's included? What's explicitly out of scope? Conversations with engineering teams to understand the actual patterns and the pain points. The scoping phase has high leverage; getting it wrong means the path is built but not adopted.
• Implementation (2 to 4 weeks). The scaffolder template itself (typically Backstage Software Templates, or the equivalent in Port, Cortex, OpsLevel, Humanitec). The integration glue (cloud-resource provisioning, CI/CD pipeline wiring, observability configuration, secrets-store registration). The documentation.
• Polish and validation (1 to 2 weeks). Testing with a friendly product team that agrees to be the first user. Fixing edge cases the design phase missed. Refining documentation based on real user friction. Building enough internal trust that other teams will adopt the path when it goes wider.

A second golden path in the same organisation typically costs 2 to 4 engineer-weeks because patterns from the first apply: the scaffolder integration is already wired, the documentation structure is reusable, the conventions for how golden paths fit into the broader IDP are established. By the third path, organisations usually have a stable per-path authoring cost of 2 to 3 engineer-weeks.

The maintenance cost

Maintenance is the often-underestimated cost line. A golden path requires roughly 10 to 20 percent of one platform engineer's time long-term per path, or $20k to $40k a year of loaded cost. The work:

• Upstream tooling changes. The CI/CD provider releases new features or deprecates old ones. The cloud provider changes recommended patterns or adds new capabilities the path should adopt. The language ecosystem moves (frameworks update, package managers change, security advisories require dependency updates).
• Edge cases. As teams adopt the path, they discover scenarios the original author did not anticipate. Some are template bugs; some are gaps in the path's scope. Each needs a small engineering response, accumulating over time.
• Documentation drift. As the template evolves, the documentation needs to keep pace. Out-of-date documentation is one of the most common reasons engineers stop trusting the path.
• Adoption support. Office hours, Slack questions, troubleshooting for teams adopting the path. The platform engineer who authored a path typically becomes the first-line support for that path for a long time.

A typical organisation that under-invests in maintenance ends up with a "graveyard" of golden paths: the path exists, but the template is out of date, the documentation is wrong, and the platform engineer who authored it has moved on. Adoption stalls; engineers stop trusting the path; the original authoring investment becomes a sunk cost.

The right number of golden paths

Most mature platform organisations end up with 3 to 6 golden paths by year two, growing to 6 to 10 by year four. The honest target is paths that cover 70 to 80 percent of new services, with explicit non-golden-path options for the remaining 20 to 30 percent of unusual cases.

Typical golden-path inventory at a 200-engineer organisation:

• Web service (HTTP-only, typically the most-used path).
• Event-driven worker (async processing, queue consumer).
• Scheduled job or cron worker (batch processing).
• Internal API service (with stricter auth defaults, internal-only network policy).
• Static site or frontend asset (with CDN deployment and asset pipeline).
• Sometimes: ML serving (with GPU defaults), data pipeline (with warehouse integration), edge worker.

Less than three paths is usually under-investment; the platform is not opinionated enough to deliver real value. More than ten paths usually means the platform team is trying to cover too many service patterns and the maintenance cost is becoming unsustainable; some of the paths probably should be sunset or merged.

Sunsetting golden paths

Sunsetting is a real cost that organisations often forget. The triggers for sunsetting a path:

• The pattern the path encodes becomes wrong. Common cause: the language ecosystem moves on (the path's framework becomes deprecated), the deployment paradigm shifts (the path's deployment target is being phased out), a regulatory requirement makes the path non-compliant (the path's defaults do not meet new security or compliance standards).
• Adoption falls below 30 percent of new services in the path's category for two consecutive quarters. Below that threshold, the maintenance investment is not paying off; either fix the path so adoption recovers, or sunset it.
• A newer golden path covers the same use case with material improvements. Continuing to maintain both paths confuses engineers about which to choose.

The cost of sunsetting: typically 2 to 4 engineer-weeks of platform-team time. The work includes migrating affected services to the replacement path (if there is one), removing the deprecated path from the scaffolder, updating documentation to reflect the deprecation, and communicating clearly to engineering teams. Plan for this; do not let dead golden paths accumulate in the catalogue.

The total annual cost at scale

For a 100-developer organisation with 4 active golden paths and one new path being authored per year:

• Maintenance: 0.5 to 0.8 FTE platform-engineer time, $100k to $190k a year.
• New authoring: 0.2 to 0.4 FTE, $40k to $90k a year.
• Total: $140k to $280k a year for the golden-paths line.

For a 500-developer organisation with 8 active paths and two new paths per year:

• Maintenance: 1.5 to 2.0 FTE, $300k to $470k a year.
• New authoring: 0.4 to 0.8 FTE, $80k to $190k a year.
• Total: $380k to $660k a year.

The line scales sub-linearly with engineering org size because mature golden paths cover more services per path at larger scale. A path at a 100-engineer organisation might cover 20 services; the same path at a 500-engineer organisation might cover 80 services. The per-service amortised cost of the path is therefore lower at larger scale.

How golden paths fit into broader platform cost

Golden paths are one of the largest lines of substantive platform-team output beyond pure operations. They are also one of the lines that most directly tracks to engineering productivity gains. For a 100-developer organisation with mature golden paths covering 70 percent of new services:

• Each new service takes about half a day of platform-aware engineering time to ship to production, down from 1 to 3 days without the path. At about $800 of saved engineering time per service.
• A typical organisation creates about 20 to 40 new services per year. Saved engineering time: $16k to $32k per year on new-service overhead alone.
• Beyond service creation, the path's ongoing impact is in the consistency of how services run: fewer custom CI/CD configurations to maintain, fewer one-off observability setups, fewer security review cycles. Hard to measure precisely; clearly meaningful.

The honest ROI on golden paths at this scale is modest in absolute terms (saved service-creation time alone does not pay back maintenance cost) but real in compound terms (fewer one-off configurations means lower long-term operational and security cost). See /roi for the broader ROI framework.

Cost bands triangulated from Team Topologies framework material, Backstage Software Templates documentation, public case studies from Spotify and others, and CNCF Platforms Working Group adoption data. Verified 2026-05-11.