A new-ish CTO looks at their engineering org, reads a few Platform Engineering posts on LinkedIn, and announces the plan: "We're going to build an internal developer platform. Self-service everything. Golden paths for every workflow." Eighteen months later, the same company has: - A Backstage instance that three teams use and the other six tolerate. - Forty-seven custom CLIs, of which maybe twelve are actively invoked. - A platform team that's grown from two engineers to nine, and still has a quarter of backlog piled up. - Developers in product teams who still deploy via a tangle of ad-hoc scripts because the "golden path" doesn't support their use case. This is the pattern, and it isn't because the platform team is bad at their job. It's because most organizations adopt Platform Engineering as a *product-building* discipline when it should be a *library-building* one. Golden paths vs paved roads The useful distinction is this: **Paved road:** the safest, most supported way to ship software at your company. It's documented, it's supported by the platform team, and if you use it, you get observability, rollbacks, and security for free. Crucially, nothing stops you from going off the road. If you do, you're on your own for the support burden, and you know it. **Golden path:** the same idea, but restrictive — you *must* use it. Non-conforming deploys are blocked at CI. Deviation requires an approval process. Every company I've seen try to build a golden path has regretted it by year two. Every company that treated its platform as a paved road has seen the adoption curve rise the way they hoped. Reason: engineers route around inconvenience. Block them, and they build a shadow path. Offer them a better road, and they'll drive on it — when it's actually better. The tax you pay for every feature you add Platform engineering has a compounding cost that doesn't show up on the first roadmap. Every feature added to the internal platform — a CLI subcommand, a new golden path, a Backstage plugin — accumulates three long-term debts: 1. **Documentation debt.** Someone has to keep the docs current, or the feature becomes invisible. 2. **Support debt.** When it breaks, the platform team's Slack explodes. 3. **Migration debt.** When the underlying tool (Kubernetes version, cloud provider API, whatever) changes, the platform team owns every wrapped feature's migration. You don't feel this tax in year one because the platform is new and shiny. You feel it in year three when a Kubernetes upgrade breaks half your custom CLIs, and the platform team spends six weeks rewriting wrappers instead of shipping new capability. At scale, the tax goes quadratic. A platform with 20 wrapped features needs to test every combination against every Kubernetes minor version. Teams that built narrowly — say, 5 features that each composed with native `kubectl` — spend a day on the same upgrade. When to build vs buy vs not-build A practical decision tree that holds up: **Is the capability core to how our company differentiates technically?** If yes, probably build. If no, probably buy (or use open source directly). **Does the open-source tool expose a good CLI or API?** If yes, *don't wrap it*. Document the paved road with the raw tool. Teach engineers to invoke `kubectl`, `terraform`, or `aws` directly. Wrapping tools in custom CLIs is the single biggest source of platform debt, because the wrapper lags the tool. **Is the capability used by 80%+ of engineering, or less?** If 80%+, building it makes sense. If less, serve the majority with the paved road and let the long tail self-serve with the raw tools. **Does the capability need to integrate multiple systems we already own?** This is the one case where custom tooling genuinely pays off. An internal dashboard that shows deploy status, cost attribution, and on-call for one service is useful and cheap to build. A CLI that wraps `helm install` in company flavor is not. The Backstage question Backstage gets its own section because it has become the default "build a platform" answer, and the answer deserves more nuance. Backstage is great for three things: service catalog, tech documentation aggregation, and software templates for scaffolding new services. If those are your bottlenecks, it earns its keep. Backstage is dangerous when it becomes a dumping ground for "platform features". Every plugin you add accumulates the taxes above, and the plugin ecosystem is not actually that deep — most organizations end up writing custom plugins, which is roughly the same cost as building without Backstage, minus the integration with the catalog you got from the base install. A reasonable heuristic: Backstage for 3-5 integrations, fine. Backstage as the UI layer for 20 integrations, you've built a product and need the product team to go with it. What to delete when the platform is too big If you're already in year two of a platform that's getting harder to maintain, here's the audit I've watched work: 1. Instrume…