What Is Platform Engineering and Why Your Team Needs It in 2026

DevOps Isn't Broken, But It's Hitting a Scaling Wall

DevOps transformed software delivery. Teams that once waited weeks for a deployment slot could suddenly ship multiple times a day. CI/CD pipelines replaced manual runbooks, infrastructure as code replaced ticket-driven provisioning, and “you build it, you run it” became the rallying cry of a generation of engineers. For teams running a handful of services, this model works brilliantly.

But something happens when an organisation grows past ten or twenty services. Each team builds its own deployment pipeline. Each team writes its own Terraform modules. Each team selects its own observability stack, its own secret management approach, its own way of provisioning a new namespace. The result is not chaos — the individual teams are often doing excellent work — but it is inconsistency, duplicated effort, and an ever-growing cognitive load on every developer.

A backend engineer who joins a new squad should not need to learn a completely different deployment workflow. A frontend developer who wants to spin up a new service should not need to become a Terraform expert. And your senior SREs should not be spending half their week answering the same infrastructure questions in Slack. This is the scaling wall, and platform engineering is the discipline that breaks through it.

What Platform Engineering Actually Is

Platform engineering is a discipline, not a tool. It is the practice of building and maintaining an Internal Developer Platform (IDP) — a self-service layer that sits between your developers and the underlying infrastructure. The platform team does not deploy your application for you. Instead, they build the golden paths that let you deploy it yourself, quickly and correctly.

An IDP provides opinionated, pre-configured workflows for the most common operations: deploy a service, provision a database, create a new microservice from a template, set up monitoring dashboards, rotate secrets. Developers get self-service — they do not need to file a ticket or wait for a platform engineer to be available. The platform team gets standardisation — every service deployed through the golden path is consistent, observable, and secure by default.

Think of it as the difference between giving every team a pile of lumber and saying “build a house” versus giving them a well-designed kit home with clear assembly instructions. Both approaches produce a house. But one produces houses that are structurally sound, up to code, and built in a fraction of the time. The platform team builds the kit. The application teams assemble it.

Critically, platform engineering treats the platform as a product. The platform team has users (developers), and those users have needs, frustrations, and alternatives. If the platform is harder to use than the DIY approach, developers will route around it. The best platform teams run user research, track adoption metrics, maintain documentation, and iterate based on feedback — just like any product team.

Platform Engineering vs. DevOps vs. SRE

These three disciplines are complementary, not competing. But the boundaries can be confusing. Here is how they differ in practice:

In a mature organisation, all three coexist. DevOps is the cultural foundation — the shared belief that development and operations are one team. SRE provides the reliability framework — SLOs, error budgets, and incident management. Platform engineering provides the tooling layer — the IDP that makes DevOps practices accessible to every developer without requiring them to become infrastructure experts.

The platform team does not replace your SREs or your DevOps culture. It amplifies them. An SRE who defines an SLO alerting standard can have the platform team bake it into every service template. A DevOps practice around trunk-based development can be enforced through the golden path CI configuration. The platform is the force multiplier.

The Anatomy of an Internal Developer Platform

An IDP is not a single product you install. It is an integration layer composed of multiple tools, each serving a specific purpose. The exact stack varies by organisation, but most IDPs share the same logical layers:

• Version control — GitHub or GitLab as the single source of truth for code, configuration, and infrastructure definitions.
• CI/CD — GitHub Actions, GitLab CI, or ArgoCD for build, test, and deployment automation. ArgoCD is increasingly popular for GitOps-based continuous delivery to Kubernetes.
• Infrastructure orchestration — Terraform for cloud resources, Crossplane for Kubernetes-native infrastructure provisioning. The platform team writes the modules; developers consume them through the IDP.
• Service catalog — Backstage (by Spotify) is the dominant open-source option. It provides a single pane of glass for all services, their owners, their documentation, their APIs, and their dependencies.
• Observability — Grafana, Datadog, or New Relic for metrics, logs, and traces. The platform team pre-configures dashboards and alerting rules so every new service is observable from day one.
• Security and policy — OPA (Open Policy Agent) with Gatekeeper or Kyverno for admission control, ensuring every deployment meets your security and compliance baselines.

The glue that holds these layers together is the service catalog. Backstage acts as the portal that developers interact with. They register their services, browse documentation, trigger golden path workflows, and view their service health — all from a single interface.

Every service registered in Backstage starts with a catalog-info.yaml file in the repository root. This file declares the service metadata, ownership, and relationships:

# catalog-info.yaml
# Registers this service in the Backstage service catalog.
# Place this file in the root of your repository.
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-service
  description: Handles order creation, payment processing, and fulfilment.
  annotations:
    github.com/project-slug: acme-corp/order-service
    backstage.io/techdocs-ref: dir:.
    grafana/dashboard-selector: "service=order-service"
    pagerduty.com/service-id: PXXXXXX
  tags:
    - java
    - spring-boot
    - grpc
  links:
    - url: https://grafana.internal/d/order-service
      title: Grafana Dashboard
    - url: https://argocd.internal/applications/order-service
      title: ArgoCD Application
spec:
  type: service
  lifecycle: production
  owner: team-payments
  system: commerce-platform
  providesApis:
    - order-api
  consumesApis:
    - inventory-api
    - payment-gateway-api
  dependsOn:
    - resource:order-database
    - resource:order-events-topic

With this file in place, Backstage automatically discovers the service, maps its ownership to the payments team, links to its Grafana dashboard and ArgoCD deployment, and shows its API dependencies. When an incident occurs, the on-call engineer can look up the service in Backstage and immediately see who owns it, where its logs are, and what it depends on.

Golden Paths: Reducing Cognitive Load by Design

A golden path is an opinionated, pre-paved route for completing a common developer workflow. It is not a mandate — developers are free to go off-path if they have a good reason — but it is designed to be so much easier than the alternative that most developers choose it voluntarily.

The term comes from the idea that in a well-designed city, you do not need to put up “keep off the grass” signs if the paved paths go where people actually want to walk. The golden path is the path of least resistance that also happens to be the path of best practice.

Consider the most common golden path: deploying a new microservice. Without a platform, this involves creating a repository, writing a Dockerfile, configuring a CI pipeline, writing Terraform for a Kubernetes namespace and database, setting up monitoring dashboards, configuring alerting, and wiring everything together. An experienced engineer might take two to three days. A newer engineer might take a week or more, and the result will not match organisational standards.

With a golden path, the developer fills out a form in Backstage and the following happens automatically:

• A new repository is created from an approved template with the correct project structure, Dockerfile, and linting configuration.
• A CI/CD pipeline is auto-configured with build, test, security scan, and deploy stages.
• A Kubernetes namespace is provisioned with resource quotas, network policies, and RBAC bindings.
• Observability is auto-wired — Grafana dashboards, Prometheus alerting rules, and log aggregation are configured.
• The service is registered in the Backstage catalog with correct ownership and metadata.
• A PagerDuty service is created and linked to the owning team's on-call rotation.

Time to first deploy: under thirty minutes instead of two days. And every service created this way is consistent, secure, and observable from the start. Here is what the Backstage software template looks like for this golden path:

# template.yaml
# Backstage Software Template for creating a new microservice.
# Developers fill out the form in the Backstage UI and the
# scaffolder executes each step automatically.
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: new-microservice
  title: Create a New Microservice
  description: >
    Scaffolds a production-ready microservice with CI/CD,
    Kubernetes manifests, monitoring, and Backstage registration.
  tags:
    - recommended
    - java
    - kubernetes
spec:
  owner: team-platform
  type: service

  # The form developers fill out in the Backstage UI
  parameters:
    - title: Service Details
      required:
        - serviceName
        - ownerTeam
        - description
      properties:
        serviceName:
          title: Service Name
          type: string
          pattern: "^[a-z][a-z0-9-]*$"
          description: Lowercase, hyphen-separated (e.g. order-service)
        ownerTeam:
          title: Owner Team
          type: string
          ui:field: OwnerPicker
          ui:options:
            catalogFilter:
              kind: Group
        description:
          title: Description
          type: string
          maxLength: 200
    - title: Infrastructure
      properties:
        needsDatabase:
          title: Provision a PostgreSQL database?
          type: boolean
          default: true
        needsEventBus:
          title: Provision a Kafka topic?
          type: boolean
          default: false

  # The actions the scaffolder executes
  steps:
    - id: fetch-template
      name: Fetch service template
      action: fetch:template
      input:
        url: ./skeleton
        values:
          serviceName: ${{ parameters.serviceName }}
          ownerTeam: ${{ parameters.ownerTeam }}
          description: ${{ parameters.description }}

    - id: create-repo
      name: Create GitHub repository
      action: publish:github
      input:
        repoUrl: github.com?owner=acme-corp&repo=${{ parameters.serviceName }}
        defaultBranch: main
        protectDefaultBranch: true

    - id: provision-infra
      name: Provision Kubernetes namespace and resources
      action: http:backstage:request
      input:
        method: POST
        path: /api/crossplane/claim
        body:
          serviceName: ${{ parameters.serviceName }}
          database: ${{ parameters.needsDatabase }}
          kafka: ${{ parameters.needsEventBus }}

    - id: register-catalog
      name: Register in Backstage catalog
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps['create-repo'].output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml

  output:
    links:
      - title: Repository
        url: ${{ steps['create-repo'].output.remoteUrl }}
      - title: Open in Backstage
        icon: catalog
        entityRef: ${{ steps['register-catalog'].output.entityRef }}

This single template encapsulates hours of manual work into a repeatable, auditable, self-service workflow. The developer clicks “Create” and walks away with a fully wired service. The platform team maintains the template, not each individual service.

Build vs. Buy: Choosing Your IDP Strategy

One of the first decisions a new platform team faces is whether to build an IDP from scratch, assemble one from open-source components, or buy a commercial platform. Each approach has trade-offs, and the right choice depends on your team size, engineering maturity, and budget.

Open-Source Assembly (Backstage + Plugins)

Backstage is the most widely adopted open-source IDP framework. Spotify open-sourced it in 2020 and it graduated from the CNCF in 2024. You get a service catalog, software templates, TechDocs (docs-as-code), and a plugin architecture that integrates with nearly every tool in the ecosystem. The trade-off: Backstage requires significant engineering investment to deploy, customise, and maintain. You need at least one or two engineers dedicated to maintaining the Backstage instance itself — writing plugins, managing upgrades, building custom templates.

Commercial Platforms (Port, Cortex, Humanitec)

Commercial IDPs like Port, Cortex, and Humanitec offer faster time-to-value. Port provides a flexible service catalog with a no-code scorecard system. Cortex focuses on service maturity and ownership visibility. Humanitec takes an infrastructure-first approach with its Platform Orchestrator, abstracting deployment targets behind a unified API. These products reduce the engineering burden but introduce vendor lock-in and recurring license costs that can grow quickly at scale.

Custom Build

Some large organisations build entirely custom IDPs. This makes sense if you have highly specialised workflows that no existing tool supports, or if you already have significant internal tooling. Netflix, Google, and Uber all have custom platforms. But unless you have a dedicated platform engineering team of ten or more, a custom build is almost certainly premature. You will spend years building what Backstage or a commercial platform gives you in weeks.

Measuring Platform Engineering Success

A platform without metrics is a hobby project. You need to prove that the investment in platform engineering is delivering measurable value to the organisation. There are four categories of metrics that matter:

DORA Metrics

The DORA (DevOps Research and Assessment) metrics are the industry standard for measuring software delivery performance. Platform engineering should improve all four:

• Deployment frequency — how often your teams deploy to production. Golden paths reduce the friction of deployment, which increases frequency.
• Lead time for changes — the time from code commit to production deployment. Standardised pipelines eliminate the bottleneck of per-team CI/CD configuration.
• Change failure rate — the percentage of deployments that cause a failure in production. Templates that bake in testing, security scanning, and canary deployments reduce this.
• Mean time to recovery (MTTR) — how quickly you recover from a production failure. A service catalog with clear ownership and linked runbooks dramatically reduces the time to identify the responsible team and diagnose the issue.

Developer Experience Metrics

DORA metrics measure delivery performance, but they do not capture developer satisfaction directly. Add these:

• Time-to-first-deploy for a new engineer — how long it takes a new hire to push their first change to production. This is the single best proxy for platform usability. If it takes more than a day, your onboarding golden path needs work.
• Developer satisfaction surveys — quarterly surveys that ask developers to rate their experience with the platform, deployment process, and tooling. Use a Net Promoter Score (NPS) format. Track the trend, not the absolute number.
• Percentage of deploys using golden paths — this tells you whether developers are actually adopting the platform or routing around it. If adoption is below 70%, your golden paths are either too restrictive or too difficult to use.

Common Mistakes That Kill Platform Initiatives

We have seen platform engineering done well and done badly. The failure modes are remarkably consistent. Here are the four most common ways platform initiatives die:

Building a Platform Nobody Uses

The most common failure. The platform team spends six months building a beautiful IDP in isolation, launches it with fanfare, and discovers that developers have already solved their problems with shell scripts and custom tooling. The platform does not address the pain points that developers actually have. It addresses the pain points that the platform team assumed they had. The fix is simple: talk to your users before you build anything. Run interviews. Shadow developers. Identify the top three pain points and solve those first.

Over-Engineering Before You Have Users

The temptation to build the perfect platform from day one is strong, especially if your platform engineers come from an infrastructure background. They want to build a fully abstracted, multi-cloud, multi-region, policy-enforced, self-healing platform before a single developer has used it. Resist this. Start with one golden path for one workflow. Deploy it to one team. Get feedback. Iterate. Expand to the next workflow only when the first one is adopted and stable.

Not Treating the Platform as a Product

Platform teams that operate like infrastructure teams — building tools and throwing them over the wall — fail. Successful platform teams operate like product teams. They have a product manager (or a tech lead who thinks like one). They maintain a roadmap. They run user research. They track adoption metrics. They have a support channel and an SLA for responding to developer questions. If your platform team does not have a way for developers to file feature requests and bug reports, you are not running a product team.

Mandating Adoption Instead of Earning It

The worst thing you can do is force developers to use a platform that is harder than the alternative. If the golden path for deploying a service is more complex than the existing shell script a team has been using for two years, no amount of management mandates will drive adoption. Instead, you will drive resentment. The golden path must be genuinely easier, faster, and more reliable than the DIY alternative. Make it so good that developers choose it because it saves them time, not because their manager told them to.

Getting Started: A 90-Day Platform Engineering Roadmap

If you are starting from zero, here is a practical roadmap that we have seen work across organisations of 50 to 500 engineers. The goal is not to build a complete IDP in 90 days. The goal is to deliver enough value that leadership funds the next quarter.

Weeks 1-2: Discovery and User Research

Interview 10 to 15 developers across different teams. Ask them: What is the most painful part of your day? Where do you waste the most time? What do you wish someone would automate? What was the last thing you had to ask an SRE for help with? Map the top five pain points and stack-rank them by frequency and severity. Do not assume you know the answer. We have seen platform teams confidently build the wrong thing because they skipped this step.

Weeks 3-6: Build the First Golden Path

Pick the highest-impact pain point from your discovery and build a golden path for it. In most organisations, this is the deployment workflow — getting code from a feature branch to a running service in production. Standardise the CI/CD pipeline, create a reusable template, and deploy it to one willing team (your “design partner”). Measure the before and after. If time-to-deploy drops from two hours to fifteen minutes, you have your proof point.

Weeks 7-12: Service Catalog and Expansion

Deploy Backstage (or your chosen catalog tool) and register your existing services. This does not require every team to adopt the platform — you can auto-discover services from your GitHub org and enrich them with ownership data from your org chart. Once the catalog is live, developers can see all services, their owners, and their health in one place. Then expand the first golden path to two or three more teams and start building the second golden path based on your discovery data.

The Platform Is the Product

Platform engineering is not a passing trend. It is the natural evolution of DevOps in organisations that have grown beyond the point where every team can manage its own infrastructure independently. The teams that adopt it early will ship faster, onboard engineers more quickly, and spend less time on undifferentiated operational work. The teams that do not will continue to drown in duplicated pipelines, inconsistent tooling, and an ever-growing support burden on their most senior engineers.

Start small. Talk to your developers. Build one golden path. Measure the impact. Iterate. The best platforms are not built in a big bang. They are grown incrementally, driven by real developer pain points, and validated by adoption metrics. Treat your platform like a product, treat your developers like customers, and the rest will follow.