Platform Engineering in 2026: IDPs, Golden Paths, and When Your Team Actually Needs One

TL;DR / Quick answer
Platform engineering is the practice of building an internal platform — usually called an internal developer platform (IDP) — that gives developers self-service access to the infrastructure, pipelines, and guardrails they need, through paved "golden paths" instead of tickets and hand-written YAML. It is not a replacement for DevOps and it is not just a new name for your ops team: done well, the platform is run as a product, with developers as its customers. Done badly, it becomes ticket queue 2.0 with a nicer logo. Most small teams do not need a platform team at all. Most growing organizations need a small one — one or two golden paths, maintained by people who talk to their users every week. This guide explains what the discipline actually consists of, how it differs from DevOps and SRE, what to build first, and how to tell whether your organization is ready.

Originally published on DevOps Enginer.

Who this guide is for

This guide is for DevOps engineers, SREs, tech leads, and engineering managers who keep hearing that "DevOps is dead" and "everyone needs an internal platform now" and want a grounded answer to narrower questions: What is a platform, concretely? How is it different from the DevOps work we already do? And at what point does building one stop being overhead and start paying for itself?

It assumes you can read a Terraform module and a Kubernetes manifest. It does not assume your company is Spotify. Most of the famous platform stories come from organizations with thousands of engineers; most of this guide is about what survives contact with a team of five, fifteen, or fifty.

A note on where I am coming from: I have spent roughly seven years in software development and DevOps engineering in Japan, and I recently moved into a project manager role in medical systems — a data-sensitive field. That mix shapes this guide in two ways. First, I have been the engineer waiting on infrastructure, so I know which platform promises sound hollow from the receiving end. Second, managing projects has taught me that platforms fail as products far more often than they fail as technology. Where this guide touches regulated environments, it stays at the level of general best practice.

The honest 2026 status check: the prediction came due

Platform engineering spent years as a conference topic. By 2026 it is simply how larger organizations structure delivery work, and we can check that claim instead of repeating it.

Back in 2022, Gartner predicted that by 2026, 80% of large software engineering organizations would establish platform engineering teams, up from 45% in 2022. The year has arrived, and the adoption side of that prediction broadly landed: Google's DORA research in 2025 found that around 90% of surveyed organizations had adopted at least one internal platform, and roughly three quarters reported having a dedicated platform team. (Gartner prediction and what the follow-up data shows: https://eclit.com/en/knowledge-hub/platform-engineering-2026-reality-check — DORA figures summarized at http://dev.to/devopssociety/three-in-four-organisations-run-a-platform-team-and-plenty-started-one-too-early-2m7b)

But adoption is not the same as success, and the same research wave says so plainly:

• In the State of Platform Engineering Report Vol. 4 (platformengineering.org, 518 respondents), the single biggest obstacle platform teams reported was not technology — it was developer adoption (45.3%), followed by lack of a shared product vision (44.3%). Around 30% of platform teams did not measure their success at all, and only about a fifth had a dedicated platform product manager.
• DORA's 2024 research added a warning about the shape of the benefit: organizations using internal platforms saw individual and team performance gains, but also an initial dip in delivery throughput and change stability — the classic J-curve of a platform that has not matured yet.

That is the real state of platform engineering in 2026: mainstream, valuable, and routinely disappointing when it is treated as a tooling project instead of a product. The rest of this guide is about the difference.

Why DevOps alone started to hurt

Platform engineering exists because DevOps, as commonly practiced, produced three predictable problems at scale. None of them mean DevOps "failed" — they mean it succeeded, spread, and hit its limits.

1. Ticket-ops: the ops team as a help desk

The original DevOps bargain was "you build it, you run it." In many organizations what actually happened is a split personality: developers owned the code, but every environment, certificate, database, DNS change, and namespace still required a ticket to a central team. The result combined the worst of both worlds — developers blocked for days on routine work, and operations engineers spending their week on copy-paste requests instead of engineering. Ticket queues with multi-day waits for a staging environment are the single most common trigger for a platform initiative.

2. Cognitive load: every team, the whole stack

Modern delivery asks a product developer to understand their language and framework, plus Docker, Kubernetes, Helm or Kustomize, CI configuration, cloud IAM, networking, secrets management, observability tooling, and the organization's security policies. Team Topologies (Matthew Skelton and Manuel Pais) gave this a name — cognitive load — and a design rule: a team can only own so much before quality and morale degrade. When fifty teams each have to master the same infrastructure stack just to ship a CRUD service, the organization is paying that learning cost fifty times.

3. Duplication and drift

Without shared building blocks, every team assembles its own pipeline, its own Terraform layout, its own interpretation of the security baseline. The pipelines look similar — 90% identical YAML with 10% local variation — but they drift independently, so a security fix or a compliance requirement has to be applied dozens of times, in dozens of dialects, with dozens of chances to miss one. In regulated industries this is not merely inefficient; repeated, inconsistent controls are an audit problem.

Golden paths and self-service are the platform answer to all three: automate the routine ticket away, cap the knowledge a product team must carry, and make the compliant way the easy way — once, in one place.

What platform engineering actually is

Strip the buzzwords and platform engineering has four load-bearing ideas.

The platform

A platform is a curated set of capabilities — infrastructure provisioning, deployment pipelines, environments, observability, security controls — packaged so that application teams can consume them self-service, through APIs, templates, and a portal, without filing tickets or mastering every underlying tool. The CNCF's Platforms White Paper defines platforms in exactly these terms: they "curate and present foundational capabilities" to accelerate the work of internal customers such as application developers. (CNCF Platforms White Paper: https://tag-app-delivery.cncf.io/whitepapers/platforms/)

Two vocabulary points that vendors deliberately blur:

• An internal developer platform (IDP) is the whole thing: the portal, the APIs, the templates, the underlying automation, and the team that runs it.
• An internal developer portal is just the interface — the web UI and service catalog (Backstage is the famous example). A portal with nothing automated behind it is a catalog of links, not a platform. Buying a portal is the start of platform work, not the end of it.

Golden paths

A golden path (Spotify's term; also "paved road") is an opinionated, supported, end-to-end route for a common job: "create a new Java microservice," "add a PostgreSQL database," "ship a static site." It bundles the repository scaffold, CI pipeline, deployment manifests, observability wiring, and security defaults into one template a developer can consume in minutes.

Three properties make a golden path work rather than merely exist:

1. It is genuinely easier than doing it yourself. If the path takes longer than hand-rolling YAML, developers will route around it, and they will be right.
2. It is optional where it can be, and explicit where it cannot. Spotify's original framing is worth copying: the golden path is a recommendation with support behind it, not a cage. Compliance controls that must hold (encryption, logging, access policy) belong in the platform's guardrails, enforced regardless of path — not in nagging developers to follow a wiki page.
3. It is maintained. A template that scaffolded last year's stack and was never updated is worse than no template, because it manufactures legacy on day one.

Underneath the golden-path idea sits a useful discipline from Team Topologies: build the thinnest viable platform — the smallest set of capabilities that actually reduces developers' load, and nothing more. Every capability you add is a product you must support forever.

My own scale is small, so my golden path is small too — but it is a real one. Every personal project I run, this site included, follows the same paved pattern: a GitHub repository with the structure I always use, push to main, and Vercel builds and deploys. There is no ticket, no manual upload step, and no "how did I deploy this last time?" The path is the repository layout plus one convention — if it is on main, it is live — and the rollback story (revert the commit, or redeploy the previous build) is decided before the project starts, not invented during an incident. That is the golden-path idea at one-person scale: the routine decisions are made once, encoded in the structure itself, and never re-litigated per project, so starting something new costs only the interesting part — the code.

Platform as a product

This is the idea that separates platforms that get used from platforms that get mandated. The platform team treats developers as customers: it interviews them, watches where they struggle, keeps a roadmap, writes documentation, publishes changelogs, deprecates features politely, and measures whether anyone is actually happier. The CNCF's Platform Engineering Maturity Model makes this structural — it scores platforms across five aspects (Investment, Adoption, Interfaces, Operations, and Measurement) and explicitly warns that chasing the highest maturity level is not the goal; fitness for your organization is. (CNCF Platform Engineering Maturity Model: https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/)

Remember the Vol. 4 numbers from the status check: adoption is the field's #1 problem and most platform teams have no product manager. That is not a tooling gap. It is what happens when an engineering team builds a product without doing product work.

My recent move from engineering into project management changed how I read numbers like these. As an engineer, I judged internal tools by whether they were technically sound — and if a well-built tool went unused, that felt like the users' problem. Supporting junior engineers as they adopted the tools and pipelines I worked with, and now managing projects, taught me the opposite order of operations: a tool nobody adopts has failed, whatever its architecture. The questions project work forces you to ask — who is this for, what does success look like for them, how will we know, what did users say last time — are exactly the questions the Vol. 4 data says platform teams skip. Developer experience is not a polish layer on top of a platform. It is the platform's adoption strategy, and adoption is the metric everything else depends on.

Self-service with guardrails

The operational deal a platform offers is: developers can provision and deploy without asking us, because the safe defaults are built in. Policy-as-code (OPA, Kyverno), pre-approved network and IAM patterns, automatic tagging and logging, and signed-image requirements are how the platform team keeps that deal safe. This is also where platform engineering quietly does its most valuable work in regulated environments: a control implemented once in the platform is a control that holds for every service on it, with evidence generated as a by-product — a very different posture from reviewing each team's hand-built pipeline before every audit.

DevOps vs platform engineering vs SRE

These three get used as if they were rival job titles. They are better understood as three different kinds of thing: a culture, a product discipline, and a reliability practice.

Aspect	DevOps	Platform engineering	SRE
What it fundamentally is	A culture and set of practices for shared ownership of delivery	A product discipline: building internal platforms for developers	An engineering practice for reliability, applying software engineering to operations
Core question it answers	"How do we get dev and ops working as one team?"	"What platform do our developers need, and how do we run it as a product?"	"How reliable is this service, and what does the error budget let us do?"
Primary "customer"	The whole delivery organization	Internal developers (stream-aligned teams)	The service's users, via the service's reliability
Typical outputs	CI/CD pipelines, automation, collaboration rituals	IDP, golden paths, templates, developer portal, self-service APIs	SLOs, error budgets, incident response, toil reduction, capacity planning
Success looks like	Faster, safer changes; shared responsibility	Developers self-serve; less cognitive load; high voluntary adoption	Reliability targets met; toil trending down; incidents learned from
Team type (Team Topologies)	A way of working across all team types	The platform team	Often an enabling or complicated-subsystem role, or embedded in platform/stream teams

The relationships matter more than the boundaries:

• Platform engineering builds on DevOps; it does not replace it. The pipelines, infrastructure as code, and automation a DevOps culture produces are the raw material a platform packages. If your teams do not already automate and share ownership, a platform project will not fix that — it will fossilize the problem behind a portal.
• SRE practices keep both honest. A platform without SLOs and error budgets for itself becomes unaccountable infrastructure. Mature platform teams run their platform like a product service: availability targets, incident reviews, a support rotation.
• One team can wear several hats. In a 20-person company, the same two engineers may do platform work on Monday, SRE work during an incident on Tuesday, and plain DevOps automation the rest of the week. The distinctions matter for clarifying responsibilities, not for drawing org-chart boxes.

The anatomy of a platform: core capabilities

However it is assembled, a working platform usually provides the same six capabilities. This is a more honest version of the "platform stack" tables you will see in vendor decks — note that the bottom layers are the ones you probably already own.

Capability	What developers get	Common building blocks
Developer portal & service catalog	One place to find services, owners, docs, and health	Backstage, Port, Cortex, or a well-kept wiki as the honest minimum
Golden path templates	New service / database / environment in minutes, with defaults baked in	Backstage Scaffolder, Cookiecutter, repo templates, Terraform modules
Provisioning APIs & IaC	Self-service infrastructure without cloud-console archaeology	Terraform, Crossplane, cloud APIs, GitOps-driven requests
Delivery automation	Build, test, deploy, roll back — one supported route	GitHub Actions, Argo CD, Argo Rollouts, your existing CI
Security & policy guardrails	Controls enforced by default, evidence produced automatically	OPA, Kyverno, Vault / cloud secrets managers, image signing (Cosign)
Observability wiring	Logs, metrics, traces, and dashboards without per-team setup	Prometheus, Grafana, OpenTelemetry, Loki/Tempo or your cloud's equivalents

For a deeper tour of the delivery half of this stack, see this site's guide to GitOps vs traditional CI/CD — GitOps is the delivery engine inside most platforms, because a declarative, Git-audited desired state is what makes self-service safe to offer. And if you are still choosing the individual tools, the annually updated Top 10 DevOps tools guide covers the same building blocks from a tool-selection angle.

Build vs buy: the 2026 landscape, honestly

There are four realistic routes, and the right one depends mostly on how many engineers you have and how unusual your requirements are.

Route 1: Assemble it yourself around Backstage

Backstage — created at Spotify and donated to the CNCF in 2020, where it sits as an incubating project — is the default open-source portal framework, used in production by more than 3,400 organizations according to CNCF community reporting in 2026. (Backstage's growth and current state: https://dev.to/saaro_net/backstage-2026-from-service-catalog-to-ai-hub-for-developer-portals-4dn) Its catalog, software templates (Scaffolder), and TechDocs are genuinely good, and the plugin ecosystem means most tools you use already integrate.

The honest costs: Backstage is a framework, not a product. You run it, upgrade it (adopters consistently name upgrades as their sharpest pain), and staff the portal like software — because it is software. Budget a real fraction of an engineer, forever. Organizations that treat Backstage as a weekend install end up with an empty catalog and a stale UI, which is worse than no portal.

Route 2: Buy a commercial portal

Port, Cortex, and similar SaaS portals sell you the catalog/scorecard/interface layer without the framework maintenance. This is often the rational choice for mid-size organizations whose differentiation is not portal software. The trade-offs are subscription cost, a vendor's data model, and the fact — worth repeating — that a portal is only the interface. The golden paths and automation behind the buttons still have to be built by somebody, and that somebody is you.

Route 3: Platform orchestrators and managed services

A second commercial category (Humanitec's platform orchestrator is the best-known example) focuses less on the portal and more on the engine room: standardizing how workloads get deployed across your infrastructure, with the portal of your choice on top. Evaluate these when your problem is deployment sprawl across many clusters and clouds rather than service discovery.

Cloud providers have tried to sell this layer too, and 2026 delivered the cautionary tale: AWS Proton — Amazon's managed service for exactly this template-and-self-service idea, and an example the original version of this article pointed to — reaches end of support on October 7, 2026, with AWS directing customers to migrate off it. (AWS Proton end-of-support notice: https://docs.aws.amazon.com/proton/latest/userguide/proton-end-of-support.html) The lesson is not "never buy managed." It is that a platform is a long-lived commitment sitting under every service you own, so exit cost is a first-class selection criterion — one more reason open interfaces (Git, Kubernetes APIs, Terraform) age better than proprietary control planes.

Route 4: No portal at all (the right answer more often than vendors admit)

A platform does not require a portal. A versioned set of Terraform modules, a scaffolding repository template, one supported GitHub Actions workflow, an Argo CD application pattern, and a short "how to ship a service" document is a platform — the thinnest viable one. Many excellent platform efforts ran for years in exactly this shape before anyone bought or built a UI. If your developers live in Git all day anyway, meeting them there beats dragging them to a new website.

A minimum viable platform for a small organization

Suppose you have 10–60 engineers, a handful to a few dozen services, and at most one or two people who can spend real time on platform work. Here is a concrete MVP that fits in weeks, not quarters:

Scope: exactly one golden path. Pick the most common, most painful journey — usually "create a new backend service and deploy it to staging and production." Not five paths. One.

Ingredients:

1. A service template. A repository template (GitHub template repo, Cookiecutter, or Backstage Scaffolder if you already run Backstage) that generates: application skeleton, Dockerfile, CI workflow, Kubernetes manifests or Helm values, a README with the runbook skeleton, and a catalog entry.
2. One Terraform module for the standard footprint. Database, bucket, IAM role, secrets — the things every service needs, behind a small interface:

module "service" {
  source = "git::https://github.com/example-org/platform-modules.git//service?ref=v1.4.0"

  name        = "payments-api"
  environment = "staging"
  image       = "ghcr.io/example-org/payments-api:1.8.2"
  replicas    = 2
}

1. One delivery route. CI builds and pushes the image; GitOps promotes it. An Argo CD Application per service, pointed at the service's config repo, is the pattern this site's GitOps guide walks through:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payments-api-staging
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example-org/payments-api-config.git
    targetRevision: main
    path: overlays/staging
  destination:
    server: https://kubernetes.default.svc
    namespace: payments-staging
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

1. Deployment strategy defaults developers do not have to think about. Rolling updates with sensible probes for most services; canary where the risk justifies it. The trade-offs between strategies are covered in depth in the Kubernetes deployment strategies guide — the platform's job is to encode the decision, so each team does not re-derive it per service.
2. Documentation where the work happens. One page: how to create a service, how to deploy, how to roll back, who to ask. In the template repo, not in a forgotten wiki.

Explicitly out of scope for the MVP: a custom portal UI, multi-cloud anything, an internal CLI with your logo on it, and self-service for exotic infrastructure. Every one of those is a product you would have to maintain; earn the right to build them with adoption data from the first golden path.

Staffing honesty: someone has to own this — answering questions, fixing the template when Kubernetes or a base image changes, onboarding the next team. "Owned by everyone" means owned by no one, and an unmaintained golden path decays into next year's legacy generator. Even at MVP scale, name the owner.

Metrics that matter (and how to read them)

Platform teams love vanity metrics — services onboarded, portal page views, "templates created." The metrics that actually tell you whether the platform is working fall into three families. Treat all of them as trends and triangulation, not as precise instruments.

Adoption (is anyone choosing this?)

• Percentage of new services created through the golden path versus hand-rolled. This is the single most honest platform metric: it measures a choice developers make when nobody is watching.
• Active usage: how many teams deployed through the platform this month; how many services run on the current template version versus stranded on old ones.
• Voluntary vs mandated usage. Adoption you had to force tells you the platform is a tax; adoption developers pick when alternatives exist tells you it is a product.

Delivery (is work moving faster and safer?)

• The DORA four keys, measured for teams on the platform: change lead time, deployment frequency, change failure rate, and time to restore service. Compare before/after and on-platform/off-platform, and expect the J-curve the DORA research describes — an initial dip while teams migrate is normal; a dip that never recovers is a verdict.
• Time-to-first-deploy for a new service and for a new hire. Platform value concentrates here: going from "two weeks of tickets" to "an afternoon" is the story that justifies the team.

Developer satisfaction (does it feel better?)

• A short recurring survey (quarterly is fine) with two or three questions: "How easy is it to ship a change?" "Where did you lose time this month?" Free-text answers are where the roadmap hides.
• Support burden: tickets and Slack questions per team per month about infrastructure. A working platform bends this curve down; a failing one bends it up while calling the questions "engagement."

And measure the platform itself like a service: its availability, its own deployment lead time, and how long developers wait on the platform team. A platform team that cannot state its own SLOs will struggle to be believed about anyone else's.

A final caution: none of these numbers work as targets to be gamed. The quarter a lead-time target is announced is the quarter teams start splitting changes artificially. Use metrics to find friction, then go and talk to the humans experiencing it — which, not coincidentally, is also how products are built.

Anti-patterns: how platform efforts actually fail

Ticket queue 2.0. The platform team renames the ops queue "platform requests" and keeps the same process: file a ticket, wait, receive a namespace. Self-service was the entire point; if a human is still in the loop for routine work, you have built a rebrand, not a platform.

I have been on the receiving end of this pattern as an engineer: needing something routine — an access grant, an environment, a small pipeline change — and watching the work wait behind a request queue while the task it blocked would have taken a fraction of the waiting time. The frustrating part was rarely the people handling the request; it was that a short, well-understood, repeatable action required a human handoff at all. Most engineers who have lived that wait carry the same lesson into platform work: the first candidates for self-service are not the impressive capabilities. They are the boring requests that interrupt someone every single day.

Building for nobody. The team spends two quarters building a beautiful platform for the requirements they imagined, launches it, and discovers developers needed three specific things — none of which are in the platform. The Vol. 4 survey's top obstacles (adoption, no shared vision, almost no product managers) are this anti-pattern, measured. The cure is embarrassingly un-technical: pick two friendly teams, build the first golden path with them, and let their pain order your backlog.

Mandate without an escape hatch. Leadership decrees that all services must use the platform, including the 15% of workloads the golden path genuinely does not fit. Those teams now maintain both the platform's way and their real way, and they will tell every new hire the platform is a lie. A supported opt-out with clear criteria ("off-path is allowed; you own the controls the platform would have given you") produces more long-term adoption than a mandate.

Big-bang launch. A year of building, one launch day, every team expected to migrate. Platforms that try to solve everything at launch fail at striking rates in the survey literature; the ones that work start with one path, prove value with a few teams, and expand pull-first. If your platform plan has a launch date rather than a first user, reconsider it.

Platform as a rebrand of the old silo. Same team, same habits, new name — still gatekeeping, still measuring themselves on tickets closed, still surprised that developers route around them. The org chart changed; the product did not. Platform engineering is a change in what the team optimizes for (developer outcomes) before it is a change in tooling.

Portal-first vanity. Buying or building the portal before a single golden path exists, because the portal is the visible, demo-able part. You end up with a handsome catalog describing services nobody can create through it. Automate one path end-to-end first; give it a UI later if the data says a UI is the bottleneck.

Is your organization ready? A checklist

Platform engineering pays off when coordination pain exceeds platform cost. Score your organization honestly:

Signs the time is right

• [ ] Three or more teams independently maintain near-identical pipelines or Terraform, and fixes have to be repeated across all of them.
• [ ] Developers routinely wait a day or more on tickets for routine infrastructure (environments, credentials, DNS, namespaces).
• [ ] New-service setup takes days of archaeology: copying an old repo, deleting someone else's assumptions, asking in chat what the current standard is.
• [ ] A compliance or security requirement (logging, encryption, access review) must be implemented by every team separately — and verified team by team.
• [ ] New hires take weeks to make their first production deploy, mostly due to environment and process friction rather than the codebase itself.
• [ ] You can name the first two or three teams who would adopt a golden path voluntarily, and what they would want from it.

Signs to wait

• [ ] You have one or two teams and a handful of services; a shared Terraform module and a good README already carry the load.
• [ ] Nobody can be spared to own the platform — it would be a side project competing with feature work, and it will lose.
• [ ] The real problem is elsewhere: an unreliable flagship service, no CI discipline, or unclear team ownership. A platform poured over those problems preserves them.
• [ ] The motivation is a conference talk, a competitor's blog post, or a reorg that needs a headline. Platforms built to be announced are rarely built to be used.

If you scored mostly "wait," that is not failure — it is sequencing. Steal the cheap parts now (templates, shared modules, one documented deployment route — the Top 10 DevOps tools guide can help you pick the pieces), and revisit the question when duplication and waiting start to cost real weeks.

What is actually new in 2026 (and what is not)

Two developments are worth separating from the hype cycle. First, portals are becoming the interface for AI assistance: Backstage and its ecosystem have begun adding AI-agent integrations (including Model Context Protocol support since late 2025), so the service catalog doubles as structured context that makes AI help accurate instead of hallucinatory. This is promising precisely because it is boring — AI grounded in your real catalog, owners, and runbooks. Treat vendor claims of autonomous, self-driving platforms with the skepticism the adoption data above justifies; AI features do not fix a platform nobody uses.

Second, the shakeout is real. AWS retiring Proton, surveys showing many platform teams struggling to demonstrate impact, and the field's top problems being product problems — this is what a discipline maturing looks like. The teams still standing in 2026 are the ones that started small, measured something, and treated developers as customers. That is a less exciting story than "the rise of platform engineering," and it happens to be the true one.

FAQ

Is platform engineering replacing DevOps?

No. Platform engineering builds on DevOps practices — automation, infrastructure as code, shared ownership — and packages them into a product other teams consume. Organizations still need everything DevOps taught them; the platform is one delivery mechanism for it. The "DevOps is dead" framing is marketing: what is actually ending is the expectation that every product team should hand-assemble the full infrastructure stack alone.

What's the difference between an internal developer platform (IDP) and a developer portal?

The portal is the interface — the catalog and UI (Backstage is the best-known example). The IDP is the entire platform: portal plus provisioning APIs, golden path templates, delivery automation, and guardrails behind it. You can have a useful platform with no portal (templates + modules + docs), and a useless one with a beautiful portal and nothing automated behind it.

How big does a company need to be before platform engineering makes sense?

There is no magic headcount, but the pain that justifies a platform — duplicated pipelines, ticket waits, per-team compliance work — typically appears once you have several teams and a few dozen services. Below that, the thinnest viable platform (shared modules, repo templates, one documented deployment route) captures most of the benefit at a fraction of the cost. Above a few hundred engineers, some form of dedicated platform team is close to inevitable; Gartner's 80%-of-large-organizations figure reflects that.

Should we build on Backstage or buy a portal?

Backstage is the right default if you have engineers to own it as a product — it is a framework you run and upgrade, not an install-and-forget tool. Buy a commercial portal (Port, Cortex, and peers) if your scarce resource is engineering time rather than budget, or if scorecards/catalog governance are your main need. Either way, the decision that matters more is what golden paths and automation sit behind the portal; the portal itself is interchangeable in a way your templates and modules are not.

Does platform engineering mean developers no longer need to understand infrastructure?

No — it changes which infrastructure knowledge is mandatory. Developers on a good golden path do not need to be Kubernetes or cloud-networking specialists to ship a standard service, but they still own their service's behavior in production, and the platform must keep the underlying systems inspectable for when the abstraction leaks. The goal is to remove undifferentiated toil, not understanding; teams that treat the platform as magic eventually debug it during an incident, which is the worst time to learn it.

What does a platform engineer actually do day to day?

A mix of software engineering and product work: building and maintaining templates, modules, and platform services; running the platform itself to SLOs; supporting internal users (and feeding their pain back into the roadmap); writing documentation and migration guides; and deprecating old paths without breaking the teams on them. The closer the ratio gets to "building product with users" versus "processing tickets," the healthier the platform team is.

Conclusion

Platform engineering is what happened when the industry admitted two things at once: developers cannot each carry the full modern infrastructure stack, and operations teams cannot be a ticket queue for everyone else. The fix is not a tool — it is a product: a small set of golden paths, self-service with guardrails, and a team that measures itself by whether developers choose to use what it builds.

If you take one idea from this guide, take the thinnest viable platform. One golden path, two friendly teams, an owner with time to maintain it, and a metric you will actually look at. That is achievable for almost any organization reading this, it is how the success stories quietly started, and it scales into a full IDP if — and only if — the adoption data says it should.

Rabin Adhikari writes practical DevOps, Kubernetes, and CI/CD guides at DevOps Enginer, based on general engineering practice and his own projects.