As engineering organisations grow, developers are often expected to understand an increasing number of tools, deployment processes, cloud services, security controls and infrastructure requirements before they can move an application into production.
After working with CI/CD, Infrastructure as Code, Kubernetes, GitOps and self service deployment workflows, I started looking at a broader question:
How can we give developers a simple and consistent path to production without hiding the controls that make the platform secure and reliable?
This is where platform engineering and the idea of golden paths became particularly interesting to me.
In this article, I will explore how a platform team can create reusable development and deployment paths that reduce unnecessary complexity while still allowing developers to make appropriate engineering choices.
Golden Path Concept
Developer Idea
↓
Approved Application Template
↓
Standard CI/CD
↓
Security and Quality Checks
↓
Infrastructure Provisioning
↓
GitOps Deployment
↓
Observability
↓
Production Ready Application
What Is Platform Engineering?
I think of platform engineering as building reusable internal capabilities that make software delivery easier for development teams.
Instead of every team individually solving the same infrastructure problems, a platform team can provide standard capabilities such as:
The goal is not to remove engineering decisions.
The goal is to remove unnecessary repeated work.
The Problem: Every Team Builds Its Own Path
Imagine four development teams building similar API services.
Without a shared platform, the result may look like this:
Team A → Jenkins + Helm
Team B → GitHub Actions + kubectl
Team C → Jenkins + Custom Scripts
Team D → Manual Kubernetes Deployment
Each team may also solve logging, secrets, health checks and monitoring differently.
Over time, this creates:
Different deployment standards
Duplicated automation
Inconsistent security controls
Different monitoring approaches
More operational support work
Higher learning overhead for developers
Platform engineering tries to solve this problem at a shared capability level.
What Is a Golden Path?
A golden path is a recommended and supported way of performing a common engineering task.
For example, if a developer wants to create a new API service, the golden path could provide:
Create New Service
↓
Select API Template
↓
Repository Created
↓
CI/CD Included
↓
Container Pattern Included
↓
Kubernetes Configuration Included
↓
Monitoring Included
↓
Developer Starts Building
The developer starts with a working foundation instead of assembling every component from zero.
My interpretation: a good golden path should make the recommended approach easier than creating an unsupported custom solution.
Golden Paths Should Not Become Golden Cages
Standardisation is useful, but too much restriction can create a different problem.
If every application is forced into exactly the same architecture, teams may struggle when they have legitimate technical requirements.
I prefer thinking about golden paths as:
Recommended, supported and easy to use.
rather than:
The only architecture developers are allowed to use.
Teams should still have an escape path when there is a genuine engineering reason.
Designing an Application Template
A simple API golden path could begin with a standard repository structure.
service-template/
│
├── src/
│ └── application/
│
├── tests/
│
├── Dockerfile
│
├── Jenkinsfile
│
├── kubernetes/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── kustomization.yaml
│
├── monitoring/
│ └── alerts.yaml
│
└── README.md
The developer receives a foundation that already includes common engineering requirements.
Standardising Health Endpoints
One example of a useful platform standard is application health.
Instead of every development team choosing different paths, the platform could recommend:
/health/live
/health/ready
Kubernetes templates can already be configured around those endpoints.
readinessProbe:
httpGet:
path: /health/ready
port: 8080
livenessProbe:
httpGet:
path: /health/live
port: 8080
Developers do not need to redesign the Kubernetes health strategy for every service.
Standardising CI/CD
The same idea can be applied to CI/CD.
A platform team can provide a reusable pipeline pattern:
Checkout
↓
Build
↓
Unit Tests
↓
Security Scan
↓
Container Build
↓
Registry Push
↓
GitOps Update
Development teams then provide application-specific values rather than recreating the complete pipeline.
Using Configuration Instead of Duplicating Pipelines
A service could describe its build requirements through configuration.
application:
name: orders-api
language: dotnet
build:
test: true
container: true
deployment:
environments:
- dev
- test
- prod
health:
readiness: /health/ready
liveness: /health/live
The platform can interpret this configuration and apply the appropriate reusable workflow.
Standardising Security Checks
Security is another area where platform defaults can reduce inconsistency.
A golden path could automatically include:
Instead of asking every developer to remember every security step, the platform places those controls in the delivery path.
Important: platform defaults should reduce mistakes, but application teams still remain responsible for understanding and addressing security issues specific to their software.
Infrastructure Should Also Have a Golden Path
The same principles can be applied to infrastructure provisioning.
Instead of asking developers to create complete Terraform configurations, the platform can expose approved infrastructure modules.
Developer Requests Database
↓
Platform Selects Approved Terraform Module
↓
Environment Policy Applied
↓
Terraform Plan
↓
Approval if Required
↓
Infrastructure Provisioned
Building a Service Catalogue
As the number of applications grows, developers need a simple way to discover what already exists.
A service catalogue could contain:
{
"service": "orders-api",
"owner": "orders-team",
"repository": "git.example.com/orders-api",
"runtime": "kubernetes",
"language": "dotnet",
"environments": [
"dev",
"test",
"prod"
],
"health": "HEALTHY"
}
The catalogue becomes a central place for understanding service ownership and operational information.
Developer Experience Should Be Treated Like a Product
This was one of the biggest shifts in my thinking.
If developers are users of an internal platform, the platform team should understand their experience just as a product team tries to understand its customers.
That means asking questions such as:
How long does it take to create a new service?
How many manual steps are required?
Where do developers commonly get blocked?
Which documentation is difficult to understand?
Which tasks repeatedly require platform team support?
Which platform features are actually being used?
Measure the Developer Experience
A platform should not be considered successful only because it exists.
I would want to measure outcomes such as:
Service creation time
How long does it take to create a production-ready service?
Deployment lead time
How long does an approved change take to reach an environment?
Platform adoption
How many teams are using the supported golden path?
Deployment success rate
How many deployments complete successfully?
Support requests
Are repetitive DevOps support requests reducing?
Listen to Developer Feedback
Platform teams can easily build features they believe developers need without confirming whether those features actually solve the right problems.
I prefer a feedback cycle:
Build Platform Capability
↓
Developers Use It
↓
Measure Friction
↓
Collect Feedback
↓
Improve Golden Path
↓
Repeat
This turns the platform into an evolving internal product rather than a one-time infrastructure project.
Platform APIs Before Portals
A visual portal can improve developer experience, but I do not think the portal should contain all platform logic.
I prefer a layered architecture:
Developer Portal
↓
Platform API
↓
Policy and Workflow Layer
↓
CI/CD + Terraform + GitOps + Kubernetes
This means the same platform capabilities could later be used through:
Web portal
CLI
API
Automation workflows
Policy Should Be Part of the Platform
Golden paths become much more useful when operational policies are built into them.
For example:
deployment_policy:
dev:
approval_required: false
test:
approval_required: false
prod:
approval_required: true
security_scan_required: true
minimum_replicas: 2
Policies become reusable and consistent rather than depending on individual teams remembering them.
Give Developers Useful Feedback
Platform errors should explain what developers need to do next.
Instead of:
Deployment validation failed.
I prefer:
Deployment validation failed.
Production deployments require at least two replicas.
Current configuration: 1 replica
Required minimum: 2 replicas
Good developer experience is often about making the correct next action obvious.
Create an Escape Path
Not every application will fit the default platform model.
A team may genuinely need:
The platform should provide a documented exception process rather than forcing teams to work around it secretly.
Golden Path Works?
↓
Yes → Use Supported Platform
No → Document Requirement
↓
Architecture Review
↓
Approved Exception
The Platform Team Should Reduce Toil
A useful signal for platform opportunities is repeated manual work.
If a platform engineer repeatedly receives requests such as:
"Can you create a deployment pipeline?"
"Can you create a namespace?"
"Can you configure monitoring?"
"Can you deploy this application?"
"Can you create another environment?"
those repeated requests may indicate a capability that should become self service.
A Platform Is a Product, Not a Collection of Tools
Another lesson for me is that installing Kubernetes, Jenkins, Terraform and Argo CD does not automatically create a platform.
Those are enabling technologies.
The platform is the experience and capability created by combining them intentionally.
Kubernetes
+
Terraform
+
CI/CD
+
GitOps
+
Security
+
Observability
+
Developer Experience
↓
Internal Developer Platform
What Technical Leadership Looks Like in Platform Engineering
Platform engineering also changed how I think about technical leadership.
Leadership is not only choosing technologies or writing the most complex automation.
It also means making decisions that help other engineers succeed.
That includes:
Identifying repeated engineering problems
Creating reusable solutions
Defining sensible standards
Balancing consistency with flexibility
Listening to developer feedback
Reducing unnecessary operational complexity
Making secure behaviour easier
Measuring whether the platform is actually helping
The success of the platform should ultimately be visible in the productivity and reliability of the teams using it.
Final Platform Architecture
Developers
↓
Developer Portal / CLI / API
↓
Service Catalogue
↓
Golden Path Templates
↓
Platform APIs
↓
Policy + Identity + Permissions
↓
CI/CD + Security Validation
↓
Terraform + Cloud Infrastructure
↓
GitOps + Argo CD
↓
Kubernetes
↓
Observability + Health + Audit
↓
Feedback to Developers
What I Learned from Platform Engineering
Earlier in my DevOps journey, I spent more time thinking about individual tools and automation.
The questions were often:
How can I automate this deployment?
or:
How can I provision this infrastructure?
Platform engineering made me think at a different level:
How can we create a reusable engineering experience that lets multiple teams deliver applications safely without repeatedly solving the same infrastructure problems?
That shift from individual automation to reusable capabilities is what makes platform engineering particularly interesting to me.
Conclusion
In this article, I explored how golden paths can help improve developer experience while maintaining the standards required for reliable software delivery.
We covered:
Platform engineering fundamentals
Golden paths
Application templates
Reusable CI/CD
Standard Kubernetes patterns
Infrastructure modules
Security defaults
Service catalogues
Platform APIs
Policy driven workflows
Developer feedback
Platform metrics
Escape paths
Technical leadership through enablement
The most important lesson for me is that platform engineering should not be measured by how many tools the platform team operates.
It should be measured by whether development teams can build, deploy and operate software more safely and with less unnecessary complexity.
A good golden path does not remove engineering responsibility. It provides a strong starting point, sensible defaults and reusable automation so developers can spend more time solving product problems.
My next step: As I continued thinking about platform engineering, I became interested in how AI could improve developer platforms without being allowed to make uncontrolled infrastructure decisions. In the next stage of my journey, I will explore how AI can help developers understand platform capabilities, deployment problems and operational information while deterministic policies remain responsible for execution.