The golden path problem inside every internal developer platform product
Most organisations now claim to have an internal developer platform product. Yet platform engineering leaders quietly admit that developers still copy old repositories and improvise their own infrastructure and tools. The gap between the internal developer platform vision and daily software development reality is where value leaks.
At the centre of that gap sits the golden path that no one owns. Platform teams ship a new developer portal, fresh templates, and opinionated cloud infrastructure modules, but engineering teams never quite adopt them at scale. The internal developer platform product becomes a catalogue of platforms and tools rather than a coherent service that reduces cognitive load for development teams.
The data is blunt about this adoption failure. Around 45.3 % of platform teams struggle with adoption according to recent platform engineering surveys such as the State of Platform Engineering Report 2024[1], while analyst firms like Gartner estimate that most large organisations now have at least one platform team in place[2]. You can have a successful platform on paper and still watch developers route around it in practice.
The pattern is predictable in every idp implementation. The platform team owns technology choices, a product manager owns the roadmap, and no one explicitly owns the golden paths that should guide software engineering and operations teams. Without that ownership, the internal developer platform product degenerates into a set of loosely related developer platforms and infrastructure components.
Platform-as-a-product is the right idea, but it is implemented in the wrong order. Leaders start with platform engineering tooling, Kubernetes clusters, and cloud management, then bolt on a developer portal and call it an idp. The result is an internal platform idp that optimises for infrastructure management rather than for developer experience and software development outcomes.
A better framing is simple and demanding. Treat the golden paths as the actual internal developer platform product, and treat everything else in the platform as a library that supports those paths. When you do that, the developer platform becomes a way to improve developer flow, not a monument to infrastructure complexity.
Golden paths are not documentation pages or slide decks. They are executable workflows that connect code, infrastructure, security checks, and operations practices into a single paved road for engineering teams. When those workflows are missing or fragmented across tools, developers fall back to bespoke scripts and tribal knowledge.
Look at how Spotify, Netflix, and other early adopters of platform engineering talk about their developer platform. They emphasise opinionated defaults, self-service infrastructure, and clear contracts between platform teams and product teams, not just a list of tools. Spotify’s Backstage, for example, helped cut onboarding time for new services from weeks to days by standardising templates and service ownership data[3]. A typical internal developer platform product that follows this pattern might reduce time to first production deploy for a new service from 20–30 days of ad hoc work to under a week on a paved road, while also cutting incident rates for new services by double-digit percentages. Your internal developer platform product should do the same, or it will quietly become shelfware.
Make the golden path the product, not the platform stack
The most common failure mode for an internal developer platform product is confusing the platform stack with the product itself. A pile of cloud infrastructure, CI pipelines, and security scanners is not a product until a developer can ship a new service in hours without reading a manual. That is the standard your platform team should adopt.
In a healthy model, the golden paths are the product and the platforms are implementation details. A golden path for a new microservice, for example, should define the code layout, the infrastructure resources, the observability defaults, and the security policies in one coherent flow. The internal developer only sees a single developer portal entry that provisions everything with sane best practices.
This is where platform-as-a-product thinking usually stops too early. Leaders hire a product manager for the developer platform, but that person ends up managing a backlog of tools rather than outcomes for development teams. The roadmap fills with items like “migrate to the new idp” or “add support for another cloud provider” instead of “cut time to first production deploy for a new service by 50 %”.
Ownership must shift from technology components to golden paths. Someone on the platform team should be accountable for the end-to-end experience of shipping a new service, updating an existing one, and retiring a legacy application. That person should work directly with engineering teams, operations teams, and security to keep the golden paths aligned with real software engineering practices.
Events like KubeCon now dedicate full tracks to platform engineering, and the discussions around what platform engineering day at KubeCon actually changed show the shift from cluster management to developer experience. The lesson is clear for any internal developer platform product. If your platform idp conversations are still dominated by Kubernetes versions and not by developer experience metrics, you are optimising the wrong layer.
Golden paths should be boring on purpose. They should lag the bleeding edge of tools and frameworks by at least two years, trading novelty for stability, predictable operations, and repeatable security practices. The platform team can still experiment with new platforms and tools, but those experiments should not leak into the default paths until they are proven in production.
That deliberate conservatism is how you build a successful platform that engineering teams trust. When a developer chooses the golden path, they should know that the infrastructure, the management workflows, and the operations playbooks have already survived real incidents. The cost of being wrong on the golden path is far higher than the cost of being slightly behind the latest framework release.
Once you define the golden paths as the internal developer platform product, everything else becomes a library. Platform engineering teams can maintain reusable modules, infrastructure blueprints, and code templates that advanced teams can compose differently. But the default for most development teams should remain the paved road, not the toolbox.
Measuring adoption without lying to yourself
Most internal developer platform product dashboards look healthy until you ask a simple question. How many developers shipped their last production change entirely through the golden paths. If you cannot answer that with real data, your adoption story is probably optimistic.
Three measurement traps show up again and again in idps. The first is telemetry bias, where platform teams instrument the developer portal and CI pipelines but ignore the shadow scripts and manual cloud console clicks that bypass the platform. The second is the “we have dashboards” trap, where colourful charts hide the fact that only a small fraction of engineering teams use the platform for critical services.
The third trap is cherry-picked satisfaction metrics. A high Net Promoter Score from a handful of enthusiastic developers does not mean the internal developer platform product is a successful platform across the organisation. You need hard adoption metrics that tie platform usage to software development outcomes, such as lead time for changes, incident rates, and on-call load for operations teams.
Start with a brutally simple metric. For each production service, ask whether its code, infrastructure, and runtime operations are managed primarily through the internal developer platform product or through bespoke paths. That service-level view forces platform teams to confront where the golden paths are actually used.
Then segment by team and by stack. Some development teams will embrace the platform idp quickly, especially if they are building new services in the cloud with modern practices. Others, often those maintaining legacy software, will cling to old workflows unless the platform team invests in migration paths and clear incentives.
Financial metrics matter as well. If your internal developer platform product does not reduce infrastructure management overhead, cut time spent on repetitive security reviews, or improve developer throughput, it is not earning its budget. Tie platform engineering investments to concrete ROI measures, such as reduced time to onboard a new team or fewer production incidents per quarter.
To make this actionable, define a minimal golden-path dashboard. Track the percentage of production deployments triggered via the idp, median time from repository creation to first production release on the golden path, and the number of services fully migrated to standard workflows. For example, a basic query against CI logs might count distinct services where the last successful deployment job was run by the idp pipeline, while a complementary query against your deployment tooling can measure how many production releases in the last 30 days originated from golden-path workflows rather than custom scripts. Simple filters on repository tags, pipeline names, or deployment environments usually provide this data without new infrastructure.
Finally, remember that metrics are only useful if they change behaviour. If the platform team keeps shipping new tools while adoption stalls, you are optimising vanity metrics instead of developer experience. The goal is not to have the most features in your idp, but to have the fewest steps between an idea and reliable code running in production.
A 90-day reset plan for a stalled internal developer platform product
When an internal developer platform product stalls, leaders often respond with more tools. They add another CI system, another cloud account, or another security scanner, hoping that one more feature will finally attract developers. That instinct is understandable and usually wrong.
A 90-day reset should start with ruthless focus on the golden paths. In the first 30 days, embed members of the platform team directly into two or three representative engineering teams and operations teams. Ask them to ship a real service using only the current developer platform, and document every workaround, manual step, and missing capability.
Those embedded sprints will expose the true cognitive load imposed by your idp. You will see where the developer portal hides critical actions behind confusing navigation, where infrastructure management requires arcane knowledge of cloud providers, and where security checks feel like random obstacles instead of integrated practices. Treat this as user research for the internal developer platform product, not as a compliance exercise.
In the next 30 days, redesign one or two end-to-end golden paths based on that research. For example, define a single flow for creating a new service that provisions infrastructure on Google Cloud, sets up observability, configures security policies, and registers the service in the developer portal. Make sure the path works equally well for small teams and larger engineering organisations.
During this phase, align platform engineering with your broader software engineering strategy. Use resources like guides on building the next generation of foundational frameworks to benchmark your architecture choices. The goal is to ensure that your internal developer platform product reinforces, rather than fragments, your core software development frameworks.
The final 30 days are about hardening and rollout. Apply the “boring on purpose” rule by choosing stable tools and platforms for the golden paths, even if more fashionable options exist. Document the paths in the developer portal, run internal training with development teams, and set explicit expectations that new services should follow these golden paths unless there is a clear, approved exception.
Throughout the 90 days, keep the scope narrow. You are not rebuilding the entire idp or rewriting every piece of infrastructure as code. You are proving that a small number of well-designed golden paths can improve developer productivity, reduce incidents for operations teams, and create a more successful platform narrative for executives.
To avoid slipping back into tool-first thinking, bake measurement into the reset. For each redesigned path, track baseline and post-rollout metrics such as time to first deploy, number of manual steps per release, and incident rate for services on the new workflow. Even a 20–30 % improvement on these indicators is usually enough to justify further investment and to demonstrate that the internal developer platform product is moving in the right direction.
Once those paths are working, expand deliberately. Add support for more languages, more cloud regions, or more complex service topologies, but always through the lens of the golden paths as the internal developer platform product. The future of platform engineering belongs to organisations that treat the platform as a means and the paved road as the outcome, not the keynote demo but the third quarter in production.
Key figures shaping internal developer platforms
- Gartner estimates that around 80 % of large enterprises now operate at least one internal platform team, yet many report slower than expected adoption of their internal developer platform product, highlighting a persistent execution gap between platform engineering strategy and day-to-day software delivery[2].
- Industry surveys on platform engineering, including the State of Platform Engineering Report 2024, show that approximately 45.3 % of platform teams struggle with adoption of their idps, meaning nearly half of these investments fail to reach most developers and engineering teams[1].
- Backstage, the open source developer portal from Spotify, remains widely deployed, but managed Backstage-based services such as Roadie report growing demand, indicating that organisations increasingly prefer managed idps over self-hosted platforms to reduce operational overhead and focus internal effort on golden paths[3].
- The Crossplane project, which enables infrastructure management through Kubernetes-style declarative APIs, continues to mature with recent releases improving custom provider support, signalling that the infrastructure as code layer for internal developer platforms is stabilising and making it easier to encode golden paths as reusable abstractions[4].
- Major cloud providers such as Google Cloud, Amazon Web Services, and Microsoft Azure now offer opinionated blueprints and platform engineering tooling, reflecting a broader shift from raw cloud primitives toward higher-level internal developer platform product patterns that emphasise paved roads and standardised workflows[5].
[1] State of Platform Engineering Report 2024, Humanitec and partners. [2] Gartner research on platform engineering and internal developer platforms, 2023–2024. [3] Spotify engineering blog and public case studies on Backstage and managed Backstage offerings. [4] Crossplane project release notes and community updates. [5] Public documentation and announcements from major cloud providers on platform engineering blueprints and opinionated stacks.