Here's an uncomfortable truth. Most engineering teams in 2026 are still losing a huge chunk of their sprint capacity to something that has nothing to do with writing features: waiting. Waiting on environment provisioning. Waiting on access approvals. Waiting on a DevOps engineer to spin up infrastructure that should take two minutes but takes two days.
If that sentence made you wince, you already know why platform engineering has become the defining shift in how modern teams ship software this year.
This post breaks down what an internal developer platform (IDP) actually is, why the market is growing so fast, how to build your first golden path with real code, which tools to consider, and where teams commonly get it wrong.
Why This Is Blowing Up Right Now
For years, DevOps promised speed. What it actually delivered, in a lot of orgs, was a pile of YAML files, ticket queues, and tribal knowledge locked inside one overworked infra person's head.
Platform engineering flips that model. Instead of developers filing tickets and waiting, they get a self-service layer, a golden path, that lets them provision databases, spin up environments, and deploy without needing to understand the underlying Kubernetes cluster or cloud config.
The growth here isn't just anecdotal. The global infrastructure as code market is on track to jump from $908.7 million in 2023 to $3.3 billion by 2030, with North America holding nearly 40% of the market. That kind of trajectory only happens when a category solves a real, expensive problem.
What You're Actually Building
An internal developer platform typically has four layers:
| Layer | Purpose | Common Tools |
|---|---|---|
| Self-service portal | Where developers request resources | Backstage, Port, Cortex |
| Golden paths | Pre-approved templates for common workflows | Backstage Scaffolder, Humanitec |
| IaC backend | Actually provisions the infrastructure | Terraform, Pulumi, Crossplane |
| Guardrails | Enforces security and compliance automatically | OPA, Sentinel, Kyverno |
Step-by-Step: Building Your First Golden Path
Step 1: Pick One Painful Workflow
Don't try to platform everything at once. Find the single workflow that causes the most friction across your team, usually "spin up a new service" or "get me a staging database," and start there. Interview two or three developers about what they dread doing most. That's your starting point.
Step 2: Define the Golden Path as Code
# golden-path.yaml
name: new-service
description: Scaffold a new backend service with database and CI pipeline
inputs:
service_name: string
language: [node, python, go]
database: [postgres, none]
team_owner: string
steps:
- scaffold_repo
- provision_infra
- register_in_catalog
- setup_ci_pipeline
Step 3: Wire It to Infrastructure as Code
Your golden path should never touch the cloud directly. It should trigger a versioned module underneath so every provisioned resource is auditable and reproducible.
# modules/service/main.tf
module "service_database" {
source = "./modules/postgres"
service_name = var.service_name
instance_size = "db.t3.small"
team_owner = var.team_owner
tags = {
provisioned_by = "golden-path"
environment = "staging"
}
}
Running this through a golden path instead of a manual terraform apply means every database that exists in your account can be traced back to a request, an owner, and a timestamp.
Step 4: Add a Software Catalog
This is where Backstage earns its popularity. Every service gets a catalog-info.yaml so ownership, dependencies, and docs live in one searchable place instead of a stale wiki page.
# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payments-service
description: Handles payment processing and refunds
spec:
type: service
owner: team-payments
lifecycle: production
dependsOn:
- resource:payments-db
Step 5: Bake in Guardrails, Not Roadblocks
Use policy as code so security and compliance checks run automatically at provision time instead of sitting in someone's manual review queue.
# policy/no-public-buckets.rego
package platform.security
deny[msg] {
input.resource_type == "storage_bucket"
input.public_access == true
msg := "Public storage buckets are not allowed without security team approval"
}
The goal is zero manual approval for the 90 percent of requests that are routine, so your security team only reviews genuine exceptions.
Step 6: Measure the Actual Impact
Track two numbers before and after rollout:
- Time-to-first-deploy for a brand new service
- Mean time to provision a standard resource like a database
If those numbers don't move, the platform isn't working yet, regardless of how polished the portal looks.
A Quick Example: Before and After
A mid-sized team running twelve microservices used to take an average of four days to spin up a new service, mostly waiting on a shared infra engineer to configure networking, IAM roles, and a database by hand. After building a single golden path for "new service with Postgres," that same request dropped to roughly twenty minutes of automated provisioning plus a five minute review. The infra engineer went from being a bottleneck on every request to reviewing policy exceptions a few times a week.
That's the entire value proposition of platform engineering in one before-and-after.
Where Most Teams Get This Wrong
Teams often try to build a full "platform" before they've mapped a single existing workflow. The result is an over-engineered internal product that nobody adopts because it solves problems developers weren't actually complaining about. Start narrow, prove value on one workflow, then expand based on what people actually ask for next.
This is also exactly where a lot of teams choose to bring in outside expertise for cloud architecture, DevOps automation, and platform engineering support, especially when the in-house team is stretched thin trying to ship features and build internal tooling at the same time. Getting the golden path architecture and guardrails right early saves months of rework later, and experienced hands can shortcut a lot of the trial and error described above.
FAQ
Do I need Kubernetes to do platform engineering?
No. Golden paths work on top of any infrastructure, serverless, VMs, or containers. Kubernetes just happens to be common in orgs where this pattern emerged.
Is this the same as DevOps?
No. DevOps is a culture and set of practices. Platform engineering is the product layer that makes those practices self-service instead of ticket-based.
How small a team can justify this?
Even a five person engineering team benefits from a single golden path if provisioning is currently manual and repetitive. You don't need a dedicated platform team to start, just one well-documented, automated workflow.
The Bottom Line
Platform engineering isn't a buzzword layered on top of DevOps. It's a direct, measurable response to developers losing time on friction that has nothing to do with actual engineering work. Start with one painful workflow, wrap it in a golden path, add guardrails instead of gatekeepers, and measure the time you get back.
If your team ships its first internal golden path this quarter, you're already ahead of most orgs still stuck in ticket queues.
What's the most painful manual workflow on your team right now? Drop it in the comments, there's a good chance someone here has already automated it.
Top comments (0)