Gartner published a prediction in late 2024 that got a lot of attention: by 2026, 80% of software engineering organizations would establish platform engineering teams as internal providers of reusable services, components, and tools. That was up from an estimated 55% in 2025 and roughly 15% in 2022. Those are aggressive numbers, and a year into the prediction window, the trajectory looks about right.
Our team has helped build Internal Developer Platforms for three organizations in the past 18 months — a 200-person fintech, a 60-person SaaS company, and a 2,000-person enterprise. The pattern is consistent across all three. Developers were spending between 30% and 40% of their time on infrastructure-adjacent tasks: provisioning environments, configuring CI pipelines, debugging deployment failures, waiting for access approvals, and searching documentation that was either outdated or nonexistent. The remaining 60-70% was actual product work.
Platform engineering exists to invert that ratio. The goal is to give developers a self-service interface over infrastructure so they can provision, deploy, observe, and scale their applications without filing tickets or reading 40-page runbooks.
What an Internal Developer Platform Actually Is
The term gets thrown around loosely, so let us be precise. An Internal Developer Platform (IDP) is a layer of tooling and abstraction that sits between developers and the underlying infrastructure. It provides self-service capabilities for common tasks — creating a new service, spinning up a database, deploying to staging, viewing logs, setting up monitoring — through a consistent interface.
An IDP is not a single tool. It is an assembly of tools, APIs, templates, and documentation that work together to provide a coherent developer experience. Think of it as the product that a platform team builds and maintains, where the users are the company's own developers.
The most common analogy is a paved road. Your infrastructure supports many possible paths — you could deploy to Kubernetes manually, write raw Terraform, configure Prometheus by hand. The platform team paves certain roads — pre-built, tested, documented workflows that handle the most common scenarios. Developers can still go off-road when they need to, but 80% of the time, the paved road gets them where they need to go faster and more safely.
Spotify calls these paved roads "golden paths." The naming varies across organizations — Shopify uses "tracks," Netflix uses "paved paths," others use "blueprints" or "templates" — but the concept is the same: opinionated, pre-built workflows that reduce cognitive load.
The Problem Platform Engineering Solves
To understand why this movement is growing so fast, you need to understand the problem it addresses. Modern software infrastructure is extraordinarily complex. A typical production deployment in 2026 involves Kubernetes clusters, container registries, CI/CD pipelines, service meshes, observability stacks (metrics, logs, traces), secret management, DNS configuration, TLS certificates, load balancers, database provisioning, cache layers, and CDN configuration.
Each of these systems has its own documentation, its own configuration language, its own failure modes, and its own upgrade cycle. A senior DevOps engineer can navigate all of this. A product developer who wants to deploy a new microservice should not have to.
The traditional DevOps model attempted to solve this by embedding operations knowledge into development teams. The theory was that developers who own their services should also own their infrastructure. In practice, this meant every developer needed to become a part-time infrastructure engineer. The cognitive load was enormous, and the results were uneven — some teams had infrastructure experts who kept things running smoothly, while other teams struggled with basic deployment issues.
Platform engineering takes a different approach. Instead of distributing infrastructure expertise across every team, it concentrates that expertise in a dedicated platform team that builds self-service tools for everyone else. The platform team absorbs the complexity so that product teams do not have to.
Platform Engineering vs. Traditional DevOps vs. SRE
These three disciplines are related but distinct, and the differences matter.
| Dimension | Traditional DevOps | SRE | Platform Engineering |
|---|---|---|---|
| Primary focus | Breaking down dev/ops silos, automating delivery | Reliability, SLOs, error budgets | Developer self-service, reducing cognitive load |
| How developers get infrastructure | File a ticket or configure it themselves | Consult with SRE team on reliability requirements | Self-service through a platform interface |
| Interaction model | Embedded in teams or centralized | Advisory, with on-call for production issues | Product team building tools for internal customers |
| Success metric | Deployment frequency, lead time | Uptime, error budgets, incident response time | Developer satisfaction, time-to-production, adoption rate |
| Standardization | Varies (can be team-by-team) | Focused on reliability standards | Broad: golden paths for most common workflows |
| Cognitive load on developers | High (developers own everything) | Medium (SRE handles reliability) | Low (platform handles infrastructure complexity) |
| Scaling model | Hire more DevOps engineers per team | Hire SREs proportional to service count | Build once, serve many teams |
The honest answer is that most organizations need elements of all three. Platform engineering does not replace SRE — you still need reliability engineering for production systems. It does not replace DevOps culture — you still want developers who understand their deployment pipeline. It provides a layer that makes both DevOps and SRE more effective by standardizing the common paths and reducing ad hoc work.
The Tools
Backstage: The Foundation
Backstage, originally built by Spotify and open-sourced in 2020, has become the de facto foundation for Internal Developer Platforms. It is a developer portal — a single web interface where developers can discover services, create new ones from templates, view documentation, check CI/CD status, and access any internal tooling the platform team integrates.
Backstage operates on a plugin model. The core provides a service catalog (a registry of all software components, their owners, and their metadata) and a scaffolding system (templates for creating new services). Plugins extend the portal with integrations — Kubernetes deployment status, PagerDuty on-call schedules, Grafana dashboards, GitHub pull request summaries, cost dashboards, and hundreds more.
What makes Backstage effective is not any single feature. It is the aggregation. Instead of developers switching between 12 different tools to understand the state of their service, they have one place that shows everything. The reduced context-switching is the value.
That said, Backstage has real drawbacks. The setup is non-trivial — plan for 2-4 weeks of dedicated effort to get a useful instance running. The plugin quality varies widely. The React-based frontend requires regular maintenance as Backstage releases frequent updates. And the project's documentation, while improving, still has gaps that require reading source code to resolve.
Port and Humanitec: The Managed Alternatives
For organizations that want an IDP without building it themselves, Port and Humanitec offer managed platforms.
Port provides a developer portal with a flexible data model — you define your entities (services, environments, clusters, teams) and their relationships, and Port provides the UI, API, and automation layer. It is less opinionated than Backstage, which makes it more flexible but also means more design decisions for the platform team.
Humanitec takes a different approach. Instead of a portal, it provides a platform orchestrator — a backend that manages the lifecycle of environments and deployments based on declarative score files. Developers define what they need (a web service with a Postgres database and a Redis cache), and Humanitec provisions it according to the platform team's rules.
Kratix: The Kubernetes-Native Option
Kratix, built by Syntasso, provides a framework for building platforms on Kubernetes using the Kubernetes API itself. Platform teams define "Promises" — essentially Kubernetes custom resources that represent platform capabilities. A developer creates a Promise resource (for example, a PostgresDatabase custom resource), and Kratix's reconciliation loop provisions it according to the platform team's implementation.
Kratix is interesting because it uses the same API patterns that Kubernetes operators use, which means teams already familiar with Kubernetes can build platform capabilities without learning a new paradigm.
What a Good Platform Team Looks Like
The tooling matters, but the organizational design matters more. We have seen technically excellent platforms fail because the team behind them operated like a traditional infrastructure team instead of a product team.
A good platform team treats developers as customers. This is not a metaphor — it is a literal operating model. The team conducts user research (talking to developers about their pain points), maintains a roadmap (prioritized by developer impact, not technical interest), measures adoption (not just availability), and iterates based on feedback.
Measuring adoption, not just uptime, is the critical shift. A platform that is available 99.99% of the time but that only 30% of developers actually use is failing. An SRE team measures uptime. A platform team measures: how many developers are using the golden paths? How long does it take a new developer to deploy their first service? What percentage of deployments use the platform versus ad hoc methods? Where are developers going off the golden path, and is that because the path is missing or because they do not know it exists?
The team composition matters too. A platform team needs both infrastructure expertise (people who understand Kubernetes, networking, cloud providers) and product/UX sensibility (people who can design interfaces, write documentation, and think about developer experience). The worst platform teams are staffed entirely by infrastructure engineers who build powerful systems that nobody wants to use because the interface is a 200-line YAML file with no error messages.
Golden Paths: The Core Concept
Golden paths deserve deeper explanation because they are the mechanism through which platform engineering delivers value.
A golden path is a pre-built, opinionated workflow for a common task. "Create a new Node.js microservice with a PostgreSQL database, deployed to the staging Kubernetes cluster, with CI/CD, monitoring, and alerting pre-configured" — that is a golden path. It bundles 15-20 separate infrastructure decisions into a single action.
The key word is opinionated. Golden paths make choices on behalf of the developer. The Node.js service template uses a specific base image, a specific logging library, a specific health check pattern, a specific deployment strategy. These opinions are informed by the organization's experience and requirements — security standards, operational practices, cost constraints.
Developers can deviate from golden paths when they need to. The golden path for database provisioning might default to RDS PostgreSQL with specific instance sizes and backup settings. A team that needs a different configuration can modify the template. But the 80% of teams that need a standard database get it in minutes instead of days.
The tradeoff is clear: golden paths sacrifice flexibility for speed and consistency. If your organization values developer autonomy above all else, heavy golden paths will feel restrictive. If your organization values consistency, security, and speed of delivery, golden paths are the mechanism to achieve that.
Common Anti-Patterns
Having worked on several platform engineering initiatives, we have seen the same failure modes repeatedly.
Building Without Listening
The most common anti-pattern is a platform team that builds what it thinks developers need instead of what developers actually need. The team spends six months building an elaborate environment provisioning system when developers' actual top pain point is that CI pipelines take 20 minutes. Always start with developer interviews. Always.
Over-Engineering the Platform
Some platform teams treat the platform itself as a greenfield architecture project and over-engineer it. They build custom control planes, custom APIs, custom UIs — investing enormous effort in infrastructure that could have been assembled from existing tools. A Backstage instance with a few well-designed templates delivers 80% of the value at 20% of the cost of a custom-built platform.
Mandating Instead of Attracting
If you have to force developers to use your platform, it is a bad platform. Good platforms attract adoption because they are genuinely easier than the alternative. If developers are circumventing your platform and deploying manually because it is faster, that is a signal about your platform's usability, not about developers' stubbornness.
Premature Abstraction
Building platform abstractions before you understand the use cases leads to leaky abstractions that do not match real needs. Our recommendation: handle the first 3-5 use cases manually, with a human platform engineer helping each team. Only then build the automation. You will learn more from those manual interactions than from any amount of upfront design.
Ignoring Documentation
A platform with no documentation is not a platform — it is a collection of tools that only the platform team knows how to use. Every golden path needs a getting-started guide. Every template needs an explanation of the decisions it makes. Every self-service action needs clear error messages. This is not optional. It is the difference between a product and a prototype.
Why Smaller Companies Should Care
Platform engineering discussions often focus on large organizations — 500+ developers, hundreds of microservices, multiple Kubernetes clusters. The assumption is that smaller companies do not need this level of sophistication.
We disagree. Even a 10-person engineering team benefits from golden paths. The specific implementation is different — a small team might not need Backstage or Humanitec — but the concept applies universally.
For a 10-person team, a golden path might be a well-documented Terraform module for provisioning a new environment, a GitHub Actions workflow template for CI/CD, and a Notion page explaining how to deploy. That is platform engineering. It is not fancy, but it means your 11th hire can deploy their first change on day two instead of day five.
The scaling argument for early investment is compelling. Every hour you spend documenting your deployment process and creating templates when you have 10 people saves you 10 hours when you have 50 people. The cost of not having a platform is invisible — it is the time developers spend figuring things out individually instead of building product. But it compounds relentlessly as the team grows.
Looking Forward
Platform engineering is not a fad. The underlying problem — infrastructure complexity growing faster than developer capacity to manage it — is structural and accelerating. As organizations adopt AI systems, edge deployments, multi-cloud architectures, and increasingly complex compliance requirements, the need for abstraction layers between developers and infrastructure only grows.
The organizations that will execute this well are the ones that treat it as a product discipline, not an infrastructure project. They will hire product managers for their platform teams. They will measure adoption and satisfaction, not just technical metrics. They will build incrementally, starting with the highest-impact pain points, and expand based on evidence rather than architecture diagrams.
The organizations that will struggle are the ones that approach platform engineering as "we need to build a portal" or "we need to adopt Backstage." Tools are the easy part. The hard part is building something developers actually want to use. And the only way to do that is to talk to them, watch them work, and build for their actual needs — not your assumptions about their needs.
CODERCOPS helps engineering teams build Internal Developer Platforms that developers actually adopt — from golden path design to Backstage implementation to platform team coaching. Talk to us about your platform engineering goals.
Comments