Home / Insights / Architecture and Modernization
Architecture and Modernization
Platform Engineering: Building an Internal Platform Developers Actually Use
As organisations grow, every team reinventing pipelines, infrastructure and observability becomes expensive. Platform engineering builds an internal platform with self-service golden paths. This guide explains when it pays off, how to design it as a product and how to measure success.
TopicsArchitecture and ModernizationWeb and SaaS DevelopmentDedicated Teams and Outsourcing
Key takeaways
- Platform engineering builds and runs an internal developer platform (IDP) that gives product teams self-service access to infrastructure, pipelines and operational tools.
- Golden paths — supported, opinionated ways to create, build, deploy and run services — reduce cognitive load while allowing exceptions.
- Treat the platform as a product: research developer needs, prioritise, measure adoption and satisfaction.
- It pays off when many teams duplicate the same infrastructure work; for small organisations, shared templates may be enough.
- Measure delivery speed, reliability, onboarding time and developer experience, not the number of platform features.
On this page
DevOps asked product teams to own their software from code to production. In growing organisations that often means each team builds its own pipelines, infrastructure code, monitoring and security tooling — duplicating effort and multiplying inconsistency. Platform engineering responds by providing a shared internal platform that makes the right way the easy way.
What an internal developer platform includes
| Capability | Example |
|---|---|
| — | — |
| Service creation | Templates that create a repository, pipeline, infrastructure and monitoring for a new service |
| CI/CD | Standard pipelines with security and quality gates |
| Infrastructure | Self-service environments, databases and queues provisioned through approved modules |
| Observability | Logging, metrics, tracing and dashboards configured by default |
| Security | Secrets management, policy as code, scanning built into templates |
| Developer portal | Catalogue of services, owners, documentation, scorecards |
| Cost visibility | Cost by service and team |
The platform combines existing tools behind consistent, self-service interfaces.
Golden paths
A golden path is an opinionated, supported way to do a common task — for example, “create a new HTTP API in TypeScript and deploy it to Kubernetes”. It includes templates, pipelines, defaults and documentation. Teams that follow it get speed and support; teams with good reasons can diverge, accepting more responsibility. Golden paths reduce cognitive load without forbidding innovation.
Platform as a product
- Know your users: interview developers, observe onboarding and measure where time is lost.
- Prioritise ruthlessly: solve the most painful, common problems first.
- Offer self-service through portals, CLIs and APIs rather than tickets.
- Document and support like an external product.
- Measure adoption and satisfaction, and drop features nobody uses.
When it pays off
| Signal | Suggests a platform may help |
|---|---|
| — | — |
| Many teams | Several teams build and run services independently |
| Duplicate work | Each team maintains its own pipelines and infrastructure code |
| Slow onboarding | New services or engineers take weeks to become productive |
| Inconsistent security and reliability | Controls vary widely between teams |
| Infrastructure bottlenecks | Teams wait on an operations team for routine requests |
Smaller organisations can get much of the benefit from shared templates and a single well-maintained pipeline.
Worked example: from ticket queue to self-service
A hypothetical company with 15 product teams relies on a central operations team for new environments, databases and pipeline changes. Requests take an average of a week, and each team’s pipeline differs.
- Discovery: interviews show the most common requests are new services, test environments and database provisioning.
- First golden path: a template creates a containerised service with repository, pipeline, infrastructure modules, monitoring dashboards and alerts in under an hour.
- Self-service environments: ephemeral environments per pull request, destroyed automatically after merge.
- Managed databases provisioned through approved infrastructure modules with backups, encryption and tagging built in.
- Developer portal: a catalogue showing every service, owner, documentation and health scorecard.
After six months, new services go from request to first deployment in a day rather than weeks, tickets for routine infrastructure fall sharply and security controls become consistent across teams. The platform team tracks adoption: teams that use the golden path report higher satisfaction than those who stay on custom pipelines, which informs the next priorities.
Common pitfalls
- Building in isolation: a platform designed without developer input that nobody adopts.
- Mandating too early: forcing teams onto immature paths creates resentment and workarounds.
- Too many options: a platform that supports every possible stack becomes as complex as no platform.
- Neglecting documentation: self-service fails without clear guides and examples.
- Becoming a bottleneck: if every change to the platform requires the platform team, product teams wait again.
- Ignoring cost: platforms should make cost visible per service, not hide it.
Scorecards and standards
Developer portals often include scorecards showing whether services meet standards — owner defined, runbook present, alerts configured, dependencies up to date, security scans passing. Scorecards encourage improvement without heavy governance when they are visible, fair and tied to real risks.
Team structure
A platform team typically includes infrastructure, developer tooling and reliability engineers, with a product owner. It works as an enabling partner to product teams, not a gatekeeper. Keep the team small at first and grow with demand.
Metrics
- Lead time and deployment frequency for teams on golden paths.
- Time to create and deploy a new service.
- Onboarding time for new engineers.
- Change failure rate and time to restore.
- Platform adoption and developer satisfaction scores.
- Tickets to operations for routine tasks (should fall).
A phased plan
- Discover: survey and interview teams; map common tasks and pain points.
- First golden path: one service type, end to end — template, pipeline, infrastructure, observability.
- Pilot with one or two teams; iterate on feedback.
- Add a service catalogue and documentation portal.
- Expand golden paths for other common workloads; measure and refine.
Frequently asked questions
Is platform engineering replacing DevOps?
It builds on DevOps principles, making them practical at scale by providing shared self-service capabilities.
Do we need a developer portal tool?
A portal helps with discovery and documentation, but the value comes from the golden paths behind it. Start with paths, add a portal when there is enough to show.
How big should the platform team be?
Start small — a few engineers with a product mindset — and grow based on adoption and demand.
What is the biggest risk?
Building a platform nobody uses because it does not solve real developer problems. Treat it as a product from day one.
Sources and methodology
Facts in this article were checked against the sources below on 6 November 2026. Directory data (ratings, review counts, rate bands and team sizes) changes over time and is shown as published on the date accessed. Illustrative examples are labelled as such and are not quotes.
Related reading
Continue your research
Teams spending too long on infrastructure?
Share your team structure and tooling. We will help you decide whether a platform is worth it and design the first golden paths.