This guide shows platform engineers how to evolve beyond basic service catalogs into golden paths that drive real developer adoption. Learn proven patterns for building Internal Developer Platforms that deliver measurable productivity gains through streamlined workflows, self-service capabilities, and developer-friendly abstractions.
Your internal developer platform golden paths launched three months ago. Adoption sits at 11 percent. The service catalog has 247 entries, half of them outdated. Developers still Slack the platform team for every deployment. What happened?
You built a directory when you needed a decision engine.
The Service Catalog Trap
Most organisations treat their IDP service catalog as an inventory system. They catalogue everything: microservices, databases, Kafka topics, S3 buckets, Lambda functions. The catalog grows. Ownership metadata gets assigned. YAML files proliferate. Platform teams celebrate visibility.
Then adoption stalls.
The catalog answers "what exists" but not "what should I use" or "how do I start." Developers face analysis paralysis. They see 30 PostgreSQL instances and no guidance on which pattern fits their use case. They find a React template from 2019 alongside one from last quarter with no indication of which is current. The self-service promise collapses into a support ticket.
Catalogs document the past. Golden paths encode the future you want to build.
Why Golden Paths Succeed Where Catalogs Fail
Golden paths are opinionated, maintained workflows that represent your organisation's current best practices. They are not the only way to do something. They are the recommended way, backed by real operational learnings and actively maintained by the platform team.
A golden path for deploying a new API service might include:
- Pre-configured CI pipeline templates with security scanning.
- Standard observability instrumentation and error tracking.
- Database provisioning with backup policies already applied.
- Load balancer configuration aligned with your traffic patterns.
- Deployment guardrails that prevent common production mistakes.
The path embeds decisions developers would otherwise make inconsistently. It trades flexibility for speed and reliability at scale.
Platform Engineering Golden Paths vs. Unrestricted Self-Service
Unrestricted self-service sounds empowering until you scale past 50 services. Without guardrails, you get:
- Sixteen different logging formats that your observability stack cannot correlate.
- Drift across deployment strategies that break rollback assumptions.
- Database instances provisioned without backup schedules or retention policies.
- CI pipelines missing mandatory security scans because they were optional.
Developer self-service platform capabilities succeed when they channel creativity within proven boundaries. Golden paths provide those boundaries without feeling restrictive. Developers get speed. Platform teams get consistency. Security and reliability become byproducts of the workflow rather than afterthoughts.
Building Internal Developer Platform Golden Paths That Scale
Start With One Path, Not Six
The instinct is to build golden paths for every major workflow simultaneously. This guarantees none of them ship complete.
Pick the most frequently repeated workflow where variance causes the most operational pain. For many teams, this is deploying a stateless API service. Build one excellent path that handles 80 percent of cases. Ship it. Measure adoption. Iterate based on real feedback before expanding.
A complete golden path needs:
- A service template that generates working code, not just scaffolding.
- Infrastructure as code that provisions dependencies without manual steps.
- CI and CD pipeline definitions that handle build, test, and deployment.
- Observability defaults that provide useful dashboards immediately.
- Documentation that explains when to use this path and when to deviate.
Make the Path the Default, Not an Option
If your golden path lives alongside six other ways to accomplish the same task, developers will choose based on familiarity rather than best practice. The path must be the obvious starting point.
This means:
- New service requests default to the golden path template.
- Deviations require explicit justification, not permission.
- The path is prominently featured in your IDP service catalog.
- Onboarding documentation assumes developers will use it.
The goal is not rigidity. The goal is to make the right choice the easy choice.
Instrument Adoption and Iteration
An IDP implementation guide should treat golden paths as products with lifecycle management. That means measuring:
- Time from template instantiation to first successful deployment.
- Percentage of new services using the golden path versus custom approaches.
- Support ticket volume related to golden path services versus others.
- Frequency of path updates based on production learnings.
If adoption remains low after two months, the path is solving the wrong problem or introducing too much friction. Treat this as a signal to iterate, not to build more paths.
The IDP Paved Roads Maintenance Problem
Golden paths decay without active maintenance. A path built on Kubernetes 1.24 becomes a liability when your clusters upgrade to 1.28 and deprecate critical APIs. A CI template referencing a deprecated security scanner becomes a compliance risk.
Service catalog best practices require treating paths as living infrastructure:
- Assign clear ownership with on-call responsibilities.
- Run automated tests against paths in staging environments.
- Version paths and communicate breaking changes with migration guides.
- Sunset outdated paths explicitly rather than letting them linger.
Many organisations launch golden paths as projects and wonder why they fail as products. Products need roadmaps, support processes, and feedback loops. Paths need the same.
When Catalogs and Golden Paths Work Together
A mature developer experience platform uses both. The service catalog provides discovery and ownership context. Golden paths provide opinionated starting points and standardised workflows.
The catalog shows what exists. Paths show what to build next. Together, they create a self-reinforcing system where new services follow established patterns, making the catalog more useful and paths more validated.
This requires intentional integration:
- Golden path templates automatically register services in the catalog.
- Catalog entries link back to the path used for creation.
- Drift detection flags services that diverge from their originating path.
- Path usage metrics inform which catalog entries are actively maintained.
Harness IDP Perspective: Platform Engineering Best Practices at Scale
Harness IDP was designed to centralise platform standards and enable self-service workflows across engineering teams without forcing teams into rigid catalog-only thinking.
The platform treats golden paths as first-class constructs through software templates that combine scaffolding, infrastructure provisioning, and CI/CD pipeline generation. A developer instantiates a template, and the platform handles service registration, repository creation, pipeline setup, and initial deployment in a single workflow.
Key capabilities include:
- Service catalog and ownership mapping that tracks which golden path generated each service.
- Self-service templates and golden paths with versioning and rollback support.
- Standardised CI and CD scaffolding that embeds security scanning and compliance checks.
- Visibility into service health and dependencies through centralised dashboards.
- Governance guardrails aligned with platform policies that prevent drift.
- Integration with source control, pipelines, and infrastructure workflows.
The platform assumes paths will evolve. Template versioning allows gradual migration rather than forced upgrades. Rollback capabilities let teams revert if a path update introduces issues. This operational maturity prevents the common failure mode where golden paths become abandoned prototypes.
For teams scaling beyond basic self-service, Harness IDP provides patterns for multi-environment promotion, dependency management, and progressive rollout of path updates. These are not theoretical features. They solve the actual problems that appear when 20 teams try to adopt the same golden path simultaneously.
Conclusion
Service catalogs answer "what do we have." Golden paths answer "what should we build and how". The difference determines whether your internal developer platform becomes adopted infrastructure or abandoned overhead.
Start with one excellent path. Measure adoption ruthlessly. Maintain it like production infrastructure. Expand only when the first path proves valuable. Treat the path as a product with users who need support and a roadmap that evolves with operational learnings.
The goal is not to catalogue everything. The goal is to make the right patterns effortless and the wrong patterns obvious. That shift turns platforms from documentation systems into decision engines that scale engineering velocity without sacrificing reliability.
Learn more about Harness IDP Product and IDP Documentation.
All this author’s posts
Rashmi Hegde is a staff product manager at Harness
