Internal Developer Platforms: Beyond the Golden Path

Everyone talks about golden paths. "Pave the golden path and developers will use it." In theory, this is true. In practice, large enterprises have dozens of different application archetypes — microservices, batch jobs, ML pipelines, legacy monoliths being strangled — and a single golden path serves maybe 30% of them well. The rest become exceptions, and exceptions become shadow IT.

This article describes how we designed an Internal Developer Platform for a 1,200-developer organisation with 340 services across four cloud providers. The platform needed to handle this diversity without collapsing into an uncurated menu of options.

Architecting for Multiple Archetypes

Rather than a single golden path, we designed a catalogue of six service templates, each representing a well-defined archetype: HTTP API, event consumer, scheduled batch job, ML inference endpoint, frontend application, and infrastructure module. Each template is a Backstage software template backed by a curated Terraform module with pre-wired CI/CD, observability, and security defaults.

A new service doesn't start from scratch — it starts from the closest archetype and deviates only where necessary. Deviations are tracked as Architecture Decision Records checked into the service repository. This creates a paper trail without requiring approval gates for every change.

Policy-as-Code: The Invisible Guardrail

The organisation had a history of "platform teams building things that developers ignored." The root cause was usually that the platform added friction — approval processes, mandatory reviews — that developers routed around by deploying directly via console or unmanaged scripts.

Our approach was to make compliance invisible. Instead of blocking deploys pending approval, we used OPA Gatekeeper on Kubernetes and Azure Policy with deny effects to enforce standards automatically. A container without resource limits simply doesn't schedule. A resource without required tags doesn't provision. The guardrail is structural, not procedural.

This shifted the platform team from policy police to enablers — their job became writing good policies and providing escape hatches for legitimate exceptions, not chasing compliance.

Backstage as the Developer Portal

Backstage was the right choice for this organisation's scale, but we made several non-obvious decisions in the implementation. First, we kept the Backstage instance thin — no custom plugins for things that had adequate first-party support. Every custom plugin is a maintenance burden that compounds over time.

Second, we invested heavily in the Software Catalog accuracy. An inaccurate catalog is worse than no catalog — it creates confusion and erodes trust. We implemented automated catalog-info.yaml validation in CI and a weekly drift report that flags services with stale or missing metadata.

Third, we integrated the catalog with the cost attribution model. Clicking on a service in Backstage shows its current monthly cloud cost, open alerts, deployment frequency, and DORA metrics. This single pane of glass reduced the time engineers spent context-switching between tools significantly.