Skip to content
ENFRDescribe your project

Platform engineering: one shared platform for your development teams

Platform engineering brings your developers’ tools together in one shared, self-service platform with golden paths. A definition, how it differs from DevOps, what the research shows, and where to start.

By Published on 3 October 2026

Platform engineering means building and running one internal platform shared by your development teams: the tools to create, test, deliver and run an application, brought together as self-service, with quality and security already built in. A platform team maintains it as a product, whose users are your developers.

The aim: every team spends its time on its product, rather than on a delivery pipeline it reinvents next to the one of the team next door.

Why the topic is growing

As early as October 2022, the research firm Gartner predicted that 80% of software engineering organisations would have a platform team by 2026. Google Cloud’s DORA report published in September 2025 found that 90% of the organisations surveyed use at least one internal platform, and that 76% have at least one dedicated platform team.

The reason is the same everywhere: as teams multiply, each assembles its own tools, and the same security rules, the same fixes and the same costs are duplicated without anyone seeing the whole picture.

Platform engineering and DevOps: what is the difference?

DevOps is a culture and a set of practices: developers and operators work together, automate and release often. Platform engineering does not replace it, it organises it at scale: one team provides shared, self-service capabilities to the others. The CNCF white paper on platforms (April 2023) presents it as an explicit form of the cooperation DevOps called for, and the 2024 DORA report as a method to scale these practices across an organisation.

The book Team Topologies (2019) makes the platform team one of four team types: it provides an internal product that speeds up the teams in charge of the products.

What an internal developer platform contains

The CNCF defines a platform as an integrated collection of capabilities, defined and presented according to the needs of its users. In practice, it often includes:

  • ready-to-use project and continuous integration and delivery (CI/CD) pipeline templates;
  • on-demand environments, described as code;
  • security built into every release: code and dependency analysis, secrets kept out of the code;
  • logs and metrics for every service;
  • a catalogue of services and their documentation, sometimes in a portal such as Backstage, created at Spotify and open-sourced in March 2020;
  • cost tracking per team.

Golden paths

The term comes from Spotify, which described it in August 2020: a golden path is the recommended, supported way to build a type of software, for instance a web service, from the first commit to production. Quality and security are already built in, so the easy way also becomes the safe way.

A golden path is not an obligation: a team with a specific need can leave it, visibly and within a frame. If it is bypassed often, that is a sign it needs improving.

What the research shows

The 2024 DORA report measured the effect of internal platforms: with a platform, respondents report being 8% more productive, teams perform 10% better and organisational performance rises by 6%. But the same report found an 8% decrease in delivery throughput and a 14% decrease in change stability, a result its authors call surprising.

The lesson: a platform has an adoption cost. It is built step by step, with its users, and measured, rather than imposed in one go.

When it is worth it, and when it is too early

Signs that a shared platform would save you time:

  • several teams each maintain their own delivery pipeline;
  • the same security rules are rewritten project by project, or applied to some only;
  • a new developer takes a long time to ship a first change;
  • nobody knows what pipelines and environments cost, or who uses them.

On the other hand, it is often too early with one or two teams, with nobody to own the platform as a product, or when the plan is to build a full portal before solving a real problem.

Where to start

  • Listen to the development teams: what wastes their time, what they keep reinventing.
  • Build a first brick: a golden path for a type of service you build often, with its pipeline template and its environment.
  • Run it as a product: users, feedback, measured adoption, then the next brick.

To see where you stand, the CNCF maturity model (November 2023) describes four levels: provisional, operationalized, scalable and optimizing. Our offer One delivery pipeline for all your teams lays this first brick, and the page DevOps and CI/CD describes our work on the topic.

Frequently asked questions

What is an internal developer platform?

The set of shared tools and services your developers use as self-service to create, test, deliver and run their applications, often called an IDP.

Does platform engineering replace DevOps?

No. It is a way of scaling it: the DevOps culture stays, and a platform team makes available to every team what each one used to build alone.

What is a golden path?

The recommended, supported way to build a type of software in your company, with quality and security already built in.

Do you need a portal such as Backstage?

Not to start with. A portal is a front end: it becomes useful as the catalogue of services grows. The first gains come from pipeline templates, environments and built-in security.

Sources

Facts and figures checked on 3 October 2026.