Platform Engineering Vocabulary: IDP, Golden Paths, and Developer Portals
Internal developer platform, golden path, self-service, scaffolding, and platform engineering vocabulary for engineers.
Platform engineering has quietly become one of the fastest-growing disciplines in software development. As organisations scale their engineering teams, the friction of setting up pipelines, configuring infrastructure, and navigating internal tooling starts to slow everyone down. Platform engineering exists to solve exactly that problem — and it has developed its own rich vocabulary along the way. Whether you are joining a platform team, collaborating with one, or simply reading job descriptions that mention “golden paths” and “IDPs”, this guide will help you speak the language confidently.
Core Terms
Internal developer platform (IDP) — a self-service layer built on top of a company’s underlying infrastructure and tooling. It abstracts away complexity so that application developers can provision environments, deploy services, and manage configurations without raising tickets or waiting on ops teams.
“We finally shipped the IDP last quarter. Now any engineer can spin up a new microservice environment in about ten minutes without touching Terraform directly.”
“The IDP doesn’t replace our cloud provider — it just wraps our standards around it so teams stop doing things twelve different ways.”
Golden path — the recommended, well-supported route for building and deploying software within an organisation. It is not mandatory, but it is the path that comes with documentation, tooling support, and someone to call when things go wrong.
“We call it the golden path because we’ve done all the hard work — security scanning, cost tagging, observability — it’s baked in. You can go off-road, but then you’re on your own.”
“Does your service follow the golden path? If not, the security review will take three times as long.”
Paved road — a synonym for golden path used widely at Netflix and in the broader platform engineering community. The metaphor emphasises that the path is smooth, not just correct. Some teams use both terms, where the paved road refers to the tooling and the golden path to the overall workflow.
“We spent six months paving the road for gRPC services. Now onboarding a new one takes an afternoon instead of a week.”
Self-service — the principle that developers can complete infrastructure and operational tasks on their own, through a portal or CLI, without involving another team. Self-service is the core value proposition of most IDPs.
“Before the IDP, every database request went through a Jira ticket to the platform team. Now it’s self-service — you fill in a form and it’s provisioned in minutes.”
Developer Portals and Cataloguing
Developer portal — a web interface that serves as the front door to an internal developer platform. It typically includes a software catalogue, documentation, templates, and links to internal tools. Backstage is the most widely adopted open-source framework for building developer portals.
“Our developer portal is the single place where you can find every service, its owner, its runbook, and how to deploy it. It replaced about fifteen scattered wikis.”
Backstage — an open-source developer portal framework created by Spotify, now a CNCF project. Teams use it to build their own internal portals by plugging in plugins for service cataloguing, CI/CD visibility, cloud cost dashboards, and more.
“We’re building on Backstage rather than building from scratch. The plugin ecosystem saved us months of work.”
“Backstage won’t give you a portal out of the box — it gives you the scaffolding to build one that fits your organisation.”
Software catalog — a registry of all services, libraries, APIs, and data pipelines in an organisation, typically with metadata like ownership, lifecycle stage, documentation links, and dependencies. In Backstage, the catalog is the core feature everything else plugs into.
“The software catalog finally answered the question ‘who owns this service?’ We had six things called user-service and no one knew which was canonical.”
Tech radar — a visual tool, popularised by ThoughtWorks, that categorises technologies into four rings: Adopt, Trial, Assess, and Hold. Platform teams publish internal tech radars to guide technology choices across the organisation.
“Check the tech radar before picking a new library. If it’s on Hold, you’ll need a strong argument to get it approved.”
“We moved Kafka to Adopt on the radar last month. The platform team now has a golden path for it.”
Scaffolding (service template) — a pre-configured project template that generates the boilerplate code, configuration files, and CI pipeline for a new service. When a developer creates a new microservice, scaffolding does the heavy lifting so the result already complies with internal standards from day one.
“Use the scaffolding template for new Go services. It gives you logging, tracing, a Dockerfile, and a working pipeline in about two minutes.”
“We updated the scaffolding last week to include the new security scanner. Every service created from now on gets it automatically.”
Team Structure and Cognitive Load
Platform team — a team that builds and maintains the internal developer platform. It treats other engineering teams as its customers and prioritises reducing their cognitive load. A platform team does not ship end-user features directly; it ships the tooling and infrastructure that lets other teams do so faster.
“The platform team is basically building a product — our product is the IDP. We have a backlog, a roadmap, and we run user research with developers.”
Stream-aligned team — a term from Team Topologies describing a team aligned to a flow of business value or a product area. Stream-aligned teams are the primary consumers of what platform teams build. They should be able to work autonomously without heavy coordination with other teams.
“We restructured into stream-aligned teams last year. Each team owns its full stack from database to UI, which means we need the platform to handle the undifferentiated heavy lifting.”
Team Topologies — a book and organisational framework by Matthew Skelton and Manuel Pais that defines four team types (stream-aligned, platform, enabling, complicated-subsystem) and three interaction modes. It has become the dominant mental model for how platform engineering teams position themselves within an organisation.
“If you haven’t read Team Topologies, it explains why we structured the platform team the way we did. The whole idea is minimising cognitive load on stream-aligned teams.”
Cognitive load reduction — the goal of making it easier for developers to focus on their own domain by reducing the mental effort required to operate infrastructure, understand tooling, or navigate internal systems. Platform engineering frames itself as a cognitive load reduction exercise for the rest of engineering.
“Every time a developer has to remember three different CLI tools just to deploy, that’s cognitive load we should be taking off their plate.”
Measuring Developer Experience
Developer NPS — Net Promoter Score adapted for internal developer experience. Platform teams survey developers with questions like “How likely are you to recommend our internal platform to a colleague?” to track satisfaction over time.
“Our developer NPS went from 12 to 38 after we shipped the self-service database provisioning. That’s the highest it’s been in two years.”
SPACE framework — a developer productivity framework from Microsoft Research that measures five dimensions: Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow. It is used as an alternative to simplistic metrics like lines of code or PRs merged.
“We use the SPACE framework to measure platform impact. Activity metrics alone miss the point — developer satisfaction and flow state matter just as much.”
“When the exec team asks whether the IDP improved productivity, we refer them to the SPACE report rather than arguing about deployment frequency in isolation.”
How to Use These in Conversation
These terms appear in stand-ups, design reviews, hiring conversations, and engineering blog posts. Here are a few realistic scenarios.
Scenario 1 — Onboarding a new service:
“I need to create a new payment-notification service. Do I use the scaffolding template in the developer portal, or is there a golden path doc I should follow first?”
Scenario 2 — Discussing team structure in an interview:
“My current role is on a platform team. We support about twelve stream-aligned teams and our main focus this half is cognitive load reduction — specifically self-service database migrations and a better software catalog.”
Scenario 3 — Evaluating technology choices:
“Before we commit to this new observability tool, let’s see where it sits on the tech radar. If it’s in Trial, we should document the decision. If it’s on Hold, we need a conversation with the platform team.”
Scenario 4 — Reporting platform impact:
“We’ll present the Q2 platform review to leadership using our developer NPS trend and the SPACE metrics. The IDP saved an estimated 400 hours of developer time last quarter based on self-service request volume.”
Quick Reference
| Term | Short Definition |
|---|---|
| IDP | Self-service layer over company infrastructure for developers |
| Golden path | The recommended, well-supported route for building services |
| Paved road | Synonym for golden path; emphasises smooth tooling, not just process |
| Scaffolding | Project template that generates a compliant new service automatically |
| Developer portal | Web UI that is the front door to an IDP (Backstage is common) |
| Software catalog | Registry of all services with ownership and metadata |
| Tech radar | Adopt/Trial/Assess/Hold categorisation of internal technologies |
| Cognitive load reduction | Removing mental overhead so developers focus on their domain |
| SPACE framework | Microsoft Research model for measuring developer productivity |
| Developer NPS | Internal satisfaction score for platform and tooling quality |