At a certain scale, every engineering organization hits the same wall. Developers spend hours waiting for infrastructure provisioning. New engineers take weeks to ship their first feature because nobody documented how the deployment pipeline works. Senior engineers field a constant stream of "how do I do X?" questions that interrupt deep work. The codebase has 200 services and nobody can tell you which team owns which one.
The traditional response to this was more documentation, more DevOps headcount, and more process. The modern response is platform engineering: building an Internal Developer Platform (IDP) that makes self-service the default, golden paths the path of least resistance, and cognitive load the thing you actively design against — not just hope to manage.
In 2026, platform engineering is the fastest-growing specialisation in software engineering. Teams that invest in it see DORA metrics improve, onboarding time drop, and developers — for the first time in years — describe their developer experience as something other than "painful." This guide covers everything engineering leaders need to know to build one that works.
What Is Platform Engineering?
Platform engineering is the discipline of designing, building, and maintaining the internal systems — tools, workflows, and infrastructure — that make product engineering teams more productive. Platform engineers don't build features for users. They build the foundation that makes every other engineer faster, safer, and less blocked.
The clearest way to understand it: platform engineering is treating your internal developer tooling as a product, with your own engineers as the customers. Like any product, it needs a roadmap, user research (developer experience surveys), iteration based on feedback, and a team accountable for its quality.
What Is an Internal Developer Platform (IDP)?
An IDP is the self-service layer that a platform team builds and maintains. When done well, a developer can go from "I have an idea" to "I have a running service in staging" without filing a ticket, waiting for an ops engineer, or reading 14 wiki pages. The IDP handles provisioning, CI/CD configuration, secrets management, monitoring setup, and service registration automatically.
The 5 Core Components of an IDP
The Golden Path Concept
The golden path is the central design philosophy of a good IDP. It's the opinionated, pre-built route for doing common things — creating a new service, deploying to production, adding a database, setting up monitoring. It's not the only route; it's just the one that's already configured, documented, and known to work. Engineers can deviate from the golden path when they have a good reason. But the default experience should be: follow the path, ship the thing.
"A golden path isn't about forcing engineers to do things your way. It's about making the right way easy enough that doing it wrong doesn't feel worth the effort."
The Best IDP Tools in 2026
Backstage
Backstage is the de facto standard for developer portals in 2026. Built by Spotify and donated to the CNCF, it provides a service catalog, software templates (scaffolding new services from golden-path templates), TechDocs (documentation-as-code), and a plugin ecosystem with 250+ integrations — GitHub, Jira, PagerDuty, Kubernetes, and more.
The tradeoff is setup complexity. Backstage is highly configurable but requires real engineering investment to deploy, customise, and maintain. Most large engineering organisations have one or two engineers whose primary job is the Backstage deployment. At 100+ engineers, this investment typically pays for itself within a quarter. Below 50 engineers, consider Port or Cortex instead.
Pros
- Largest plugin ecosystem (250+)
- CNCF-backed, massive community
- Fully customisable to your workflow
- TechDocs keeps docs current
- Free and open-source
- Spotify, Netflix, Zalando proven at scale
Cons
- Requires dedicated platform engineers to maintain
- Steep initial setup (weeks, not days)
- Plugin quality is inconsistent
- React/TypeScript knowledge required
Port
Port is a managed Internal Developer Platform that lets teams build a fully featured developer portal — service catalog, self-service actions, scorecards, and workflows — without writing plugin code. Where Backstage requires engineering to configure, Port's no-code/low-code model means most teams are running a production portal within days.
Port's blueprints model lets you define your own entities (services, teams, deployments, incidents) and relationships without writing code. Its self-service actions let developers trigger infrastructure operations through a UI while the platform team controls what's allowed. In 2026, Port has become the go-to choice for teams between 20–150 engineers who want IDP value without full-time platform engineering headcount.
Pros
- Live in days, not weeks
- No-code blueprint model
- Strong self-service action capabilities
- Built-in scorecards for service maturity
- Solid integrations out of the box
Cons
- Less customisable than Backstage
- Per-user cost at scale
- Vendor lock-in risk
- Smaller community than Backstage
Cortex
Cortex focuses on what many organisations need most from an IDP but struggle to build: service ownership clarity and engineering excellence tracking. Its service catalog auto-discovers your services from GitHub, PagerDuty, and Kubernetes. Its scorecards let you define engineering standards (has an on-call rotation, has SLOs defined, passes security scan) and track which services meet them.
Where Backstage and Port compete on breadth, Cortex wins on depth for catalog and quality tracking. Engineering leaders who want clear visibility into service health, ownership gaps, and compliance with internal standards consistently prefer Cortex over alternatives for that specific use case.
Pros
- Best-in-class service scorecards
- Auto-discovery from existing tools
- Strong engineering quality tracking
- Quick to set up for catalog use cases
Cons
- Narrower scope than Backstage/Port
- Self-service actions less mature
- Enterprise pricing only
Atlassian Compass
Compass is Atlassian's developer portal product, built for organisations already running Jira and Confluence. It provides a component catalog, health scorecards, team ownership mapping, and deep integration with the Atlassian ecosystem. If your engineering org lives in Jira, Compass offers the lowest-friction IDP adoption — it's already where your engineers are, your tickets are linked, and your incident data flows automatically.
Outside the Atlassian ecosystem, Compass's integrations are thinner than Backstage or Port. But for Atlassian-first organisations, the native integration beats any third-party alternative on convenience and day-one data quality.
Pros
- Native Jira and Confluence integration
- No new login or context switch for most devs
- Health scorecards out of the box
- Atlassian cloud reliability
Cons
- Only compelling inside the Atlassian ecosystem
- Less customisable than Backstage
- Thinner plugin/integration ecosystem
Tool Comparison at a Glance
| Capability | Backstage | Port | Cortex | Compass |
|---|---|---|---|---|
| Service catalog | ✓ Excellent | ✓ Excellent | ✓ Best-in-class | ✓ Good |
| Self-service actions | ✓ Full (plugins) | ✓ No-code | ~ Limited | ~ Basic |
| Software templates / scaffolding | ✓ Powerful | ✓ Good | ✗ No | ~ Basic |
| Scorecards / quality tracking | ~ Via plugins | ✓ Built-in | ✓ Best-in-class | ✓ Good |
| Plugin / integration ecosystem | ✓ 250+ | ✓ 50+ | ~ 30+ | ~ Atlassian-focused |
| Time to initial value | Weeks–months | Days | 1–2 weeks | Days (Atlassian orgs) |
| Platform eng headcount needed | 1–2 FTEs | 0–0.5 FTE | 0.5 FTE | Low |
| Open source | ✓ Yes (CNCF) | ✗ No (SaaS) | ✗ No | ✗ No |
| Best for team size | 100+ engineers | 20–200 engineers | 50+ engineers | Any (Atlassian users) |
How to Build Your First IDP: A 6-Step Playbook
Most platform engineering initiatives fail not because of the tools chosen but because they start too big. The teams that succeed start narrow, prove value fast, and expand from a foundation of trust.
-
Run a developer experience survey first Before building anything, ask your engineers where they lose the most time. You'll hear the same 3–5 answers repeatedly: "waiting for infra provisioning," "can't find who owns service X," "CI takes 40 minutes and nobody knows why." These answers become your platform team's first-quarter roadmap. Don't guess — the customers will tell you what they need.
-
Start with a service catalog, nothing else A catalog of your services with clear ownership, docs links, and on-call contacts is the highest-ROI first IDP feature. Every engineer uses it immediately. It takes 1–2 weeks to populate from your GitHub repos and PagerDuty. Port and Cortex can auto-discover most of this. Backstage requires more setup but gives you more control. Ship the catalog, get engineers using it, build trust.
-
Build one golden path end-to-end Pick the most common new-service type your org creates (a Node.js API, a Python microservice, a React app). Build a complete golden path for it: a software template that scaffolds the project, wires up CI/CD, configures monitoring, registers it in the catalog, and adds it to on-call rotation. One complete path, done properly, is worth more than five half-finished ones.
-
Add self-service infrastructure for the most-requested ops tasks Look at your ops ticket queue. The top 3 most-common requests (usually: create a database, add an environment variable, create a Kubernetes namespace) become your first self-service actions. Each one you automate eliminates a category of tickets permanently and gives developers instant gratification. Use Port's self-service actions or Crossplane for the heavy lifting.
-
Introduce scorecards to drive engineering standards Define what "production-ready" means for a service at your org: has an owner, has SLOs defined, has a runbook, passes dependency audit, has >80% test coverage. Build these into scorecards (Cortex, Port, or Backstage plugins). Make them visible but not mandatory at first — teams improve organically when they can see their score and compare to peers.
-
Measure, iterate, expand Track the metrics that matter: developer time saved per week, new service onboarding time, number of ops tickets filed vs. the prior quarter, developer satisfaction score. Share results with engineering leadership monthly. The platform team that can show "we reduced time-to-first-deploy from 3 days to 2 hours" earns the headcount and budget to keep expanding.
How to Structure a Platform Engineering Team
The platform team structure varies with org size, but a few patterns hold broadly:
Small teams (20–50 engineers): Embedded platform function
At this scale, a dedicated platform team isn't justified. Instead, designate 1–2 senior engineers with a partial platform mandate — 50% of their time on product features, 50% on internal tooling. Focus on the service catalog and one golden path. Revisit when ops ticket volume becomes a measurable drag on sprint velocity.
Mid-size (50–200 engineers): Dedicated platform team of 3–5
This is where a dedicated platform team first pays off. The team should be staffed like a product team: a platform tech lead, 2–3 engineers, and ideally a product manager or engineering manager who treats internal developers as customers and runs the platform team's backlog with the same rigour as a product team's. Avoid the trap of the platform team becoming an "infrastructure team that also maintains Backstage."
Large scale (200+ engineers): Platform as a product org
At this scale, platform engineering splits into sub-domains: infrastructure platform (compute, networking, storage), developer experience platform (portal, golden paths, tooling), and data platform (pipelines, warehouses, ML infrastructure). Each sub-domain has its own team and roadmap. Spotify, Netflix, and Airbnb all operate at this model — it's well-documented and worth studying for this phase.
How to Measure Platform Engineering Success
Platform engineering success is measured through two lenses: DORA metrics (does the platform make shipping faster and safer?) and developer experience metrics (do engineers actually love using it?).
- Deployment frequency — are teams deploying more often after the IDP launched? (Target: weekly → daily)
- Lead time for changes — how long from commit to production? (Target: <1 day for standard deploys)
- Change failure rate — are golden-path deployments safer than ad-hoc ones? (Target: <5%)
- MTTR — does pre-configured observability help teams recover faster? (Target: <1 hour)
- Onboarding time — how long does it take a new engineer to deploy their first service? (Target: same day)
- Ops ticket volume — are self-service actions actually reducing requests to your platform team? (Target: >50% YoY reduction)
- Developer NPS — quarterly survey asking developers to rate their developer experience 0–10. Track the trend; don't obsess over the absolute number.
5 Platform Engineering Mistakes to Avoid
- Building for the platform team, not for developers. The IDP exists to serve product engineers. Every feature decision should start with: "Does this make a developer's day meaningfully better?" If you're building things developers don't use, you've lost the plot.
- Trying to boil the ocean. Starting with a full Backstage deployment, full IaC self-service, full observability stack, and full golden paths simultaneously is a recipe for 12 months of work before engineers see a single benefit. Ship something small in week 3 — even just the catalog.
- Mandating the platform before it's good enough. Forcing engineers onto an incomplete, slow, or buggy internal tool breeds resentment that takes years to overcome. Make the platform so good that engineers choose it. Only introduce soft mandates (scorecard requirements, on-call rotations) once the tool is genuinely better than the alternative.
- Underinvesting in documentation. An IDP without great documentation is a black box. Engineers will opt out rather than figure out how to use it. TechDocs (Backstage), written golden path guides, and short video walkthroughs are not optional extras — they're the product.
- Ignoring the "paved road" edges. Engineers always have use cases that don't fit the golden path. A good platform team designs explicit escape hatches — documented, supported ways to deviate from the standard path when genuinely needed. Without them, engineers build their own shadow infrastructure, fragmenting the thing you were trying to unify.
Which IDP Tool Is Right for Your Team?
Manage your platform engineering roadmap in Projiq
Your platform team has a backlog, sprints, and a roadmap — just like any product team. Projiq's sprint boards, custom workflows, and role-based access give platform teams the same project management rigour as the product teams they serve.
Start Free — No Credit Card