Portal maturity year-stage

Brownfield Developer Portal Cost (Year 1-2) in 2026

Year-2 is the middle phase nobody talks about. Catalogue drift starts to bite, golden paths need a v2, the plugin upgrade tax shows up. Year-2 spend is typically 60 to 80 percent of year-1, not the 20 to 30 percent that vendor pitch decks suggest. Here is a vendor-neutral cost breakdown of what year-2 actually costs and why.

Year-2 vs year-1

60-80%

of year-1 spend, not 20-30%

Catalogue freshness

$30K-$75K

0.15 to 0.3 FTE ongoing

Golden path v2

$30K-$80K

iterating on year-1 templates

The Vendor-Deck Gap

Vendor pitch decks typically suggest year-2 maintenance cost runs 20 to 30 percent of year-1 build cost. The number is not technically wrong; the maintenance line really does sit at 20 to 30 percent. The problem is that year-2 work is not just maintenance. It is iteration: catalogue data quality work as broader use surfaces errors that the year-1 implementation did not see, golden-path v2 as the year-1 templates show their gaps, plugin upgrade tax as Backstage versions and vendor APIs evolve, ongoing adoption work for the teams that did not onboard in year-1.

The iteration line is roughly equal in size to the maintenance line. Adding them together produces the 60 to 80 percent year-2-versus-year-1 ratio that organisations consistently see in practice. This is not a sales-side dishonesty so much as a category confusion: vendors quote the maintenance work because that is what their support engagement covers; the iteration work is internal-team work that their engagement does not touch. The cost is real for the buyer regardless of whether it is in the vendor's scope.

The practical implication for year-2 budgeting: plan for 60 to 80 percent of year-1 spend, not 20 to 30 percent. Most organisations under-budget year-2 by 30 to 50 percent, which produces predictable pressure on the platform team that either degrades the portal or pulls platform-team capacity away from other commitments.

Catalogue Drift in Detail

Catalogue drift is the gradual divergence between the portal's catalogue data and reality. Year-1 produces an initial catalogue snapshot that is broadly accurate. Year-2 produces drift in four ways. Services get created without being added to the catalogue (a new service ships but the team forgets to register it). Services get deprecated without being marked as such (a service is decommissioned but the catalogue entry stays). Owners change without the catalogue being updated (engineering reorganisation moves ownership but the catalogue stays on the old team). Dependencies change without the dependency graph being updated (a service migration changes upstream dependencies but the catalogue dependency edges stay on the old shape).

Each of these is small individually. Aggregated across 6 to 18 months of normal engineering activity at a 100-engineer organisation, the catalogue can become materially inaccurate. Engineers consulting the catalogue find owners who no longer own the service, dependencies that no longer exist, services missing entirely. Trust in the catalogue erodes, fall-back to Slack-based questions resumes, and the catalogue-as-source-of-truth premise of the portal collapses.

Mitigation has two components. Automation: catalogue sync from Git (services discovered from repository manifests), ownership lookup from identity provider or CMDB (so reorganisations propagate automatically), dependency mapping from observability data (so dependency changes are detected). Discipline: catalogue updates required at service-change time (a PR template question, a CI check, or both). The combined investment is roughly 0.15 to 0.3 FTE of platform-engineer time ongoing for a meaningful catalogue-freshness practice; this is roughly $30,000 to $75,000 per year at fully loaded engineer cost.

Golden-Path v2

The first set of golden-path templates authored in year-1 covers the most common service-provisioning shape based on the platform team's best guess at year-one. By year-two, real usage has shown which templates get used and which do not, which templates miss important variants, which templates produce services that need significant post-scaffolding cleanup. Golden-path v2 is the iteration: rewrite the templates that did not work, add the variants that turned out to matter, remove the templates nobody used.

The work in year-2 typically retires 1 to 3 unused templates, rewrites 2 to 4 used-but-imperfect templates, and adds 1 to 3 new template variants based on observed demand. Total work: $30,000 to $80,000 of platform-team time. The v2 pass usually produces a noticeably better template library than v1 because the v2 work is grounded in observed usage rather than guesses. Organisations that skip the v2 pass end up with a template library that ages out of usefulness over 24 to 36 months; organisations that invest in v2 end up with a template library that has a much longer useful life.

The Plugin Upgrade Tax Hits in Full

Year-2 is the first full year of Backstage framework upgrades hitting the deployment. Year-1 typically catches the first 3 to 6 minor releases; year-2 catches a full annual cycle plus a major release. The aggregate platform-team time on framework upgrades, custom plugin compatibility tracking, and stock plugin updates is 4 to 8 engineer-weeks per year for a self-hosted Backstage with 3 to 8 custom plugins. On managed Backstage (Roadie, Coderpath) the framework upgrade tax is absorbed by the vendor for stock plugins, but your custom plugins still pay the tax. On commercial portals (Cortex, Port, OpsLevel) the Backstage upgrade tax does not apply, but each portal has its own version cadence with smaller but similar effects on the platform team. For the per-plugin economics that underpin the upgrade-tax math, see the plugin ecosystem cost page.

Frequently Asked Questions

Why is year-2 cost higher than vendor decks suggest?

Vendor decks typically suggest year-2 maintenance cost runs 20 to 30 percent of year-1 build cost. In practice year-2 runs closer to 60 to 80 percent because the work that emerges in year-2 is not maintenance, it is iteration: catalogue data quality work as broader use surfaces errors, golden-path v2 as the v1 templates show their gaps, plugin upgrade tax as Backstage versions and vendor APIs evolve, ongoing adoption work for the teams that did not onboard in year-1. None of this is technically wrong (the maintenance line really is 20 to 30 percent) but the iteration line is roughly equal in size and is consistently missing from vendor projections.

What is catalogue drift and what does it cost?

Catalogue drift is the gradual divergence between the portal's catalogue data and reality. Services get created without being added to the catalogue, services get deprecated without being marked as such, owners change without the catalogue being updated, dependencies change without the dependency graph being updated. Mitigation is automation (catalogue sync from Git, ownership lookup from identity provider, dependency mapping from observability data) and discipline (catalogue updates required at service-change time). The cost is roughly 0.15 to 0.3 FTE of platform-engineer time ongoing for a meaningful catalogue-freshness practice; this is roughly $30,000 to $75,000 per year.

What is golden-path v2 and why does it cost so much?

The first set of golden-path templates authored in year-1 covers the most common service-provisioning shape based on the platform team's best guess at year-one. By year-two real usage has shown which templates get used and which do not, which templates miss important variants, which templates produce services that need significant post-scaffolding cleanup. Golden-path v2 is the iteration: rewrite the templates that did not work, add the variants that turned out to matter, remove the templates nobody used. Typical cost: $30,000 to $80,000 in year-2 for a meaningful golden-path v2 pass.

What is the plugin upgrade tax in year-2?

Year-2 is the first full year of Backstage framework upgrades hitting your deployment. Backstage releases minor versions roughly monthly and a major version annually; each release can require small to moderate plugin updates. The aggregate cost across a custom plugin set of 3 to 8 plugins is 4 to 8 engineer-weeks per year. On managed Backstage (Roadie, Coderpath) the framework upgrade tax is absorbed by the vendor for stock plugins; your custom plugins still pay the tax. On commercial portals (Cortex, Port, OpsLevel) the framework upgrade tax does not apply in the Backstage sense but each portal has its own version cadence with similar (smaller) effects.

What about ongoing adoption work?

Year-2 adoption work is roughly half of year-1 adoption work but it is still material. Three categories: onboarding the teams that did not onboard in year-1 (typically the teams that were less convinced or had higher switching cost), iterating on the workflows that did not pick up traction (changing them, retiring them, or deepening the adoption push), and handling the ownership churn that accompanies engineering reorganisations (team A used to own service X, now team B does). Typical cost: 0.1 to 0.3 FTE of platform-engineer time, or $20,000 to $75,000 per year.

What is the realistic year-2 cost relative to year-1?

Year-2 cost typically lands at 60 to 80 percent of year-1 cost across most paths. For a $200,000 year-1 budget, year-2 is typically $120,000 to $160,000. The breakdown: catalogue drift work ($30,000 to $75,000), golden-path v2 ($30,000 to $80,000), plugin upgrade tax ($15,000 to $50,000), ongoing adoption work ($20,000 to $75,000), miscellaneous ($25,000 to $50,000). The pattern is consistent across self-hosted, managed Backstage, and commercial portal paths because the cost categories that emerge in year-2 are largely path-independent.