There's a failure mode I've seen repeat itself across enough engineering organizations that I've stopped being surprised by it. A team starts small — five engineers, tight feedback loops, everyone deploys by running a script someone wrote on a Saturday. It works. Things ship. Then the team grows to fifteen, twenty, twenty-five people, and suddenly the same deployment script is a source of 3 AM incidents. Onboarding takes three weeks and still leaves people guessing. The senior engineers spend half their time unblocking everyone else instead of building things.
The team isn't broken. The infrastructure around it is. And the fix isn't another runbook or a longer onboarding doc — it's an Internal Developer Platform.
What an IDP Actually Is
An Internal Developer Platform (IDP) is the sum of tools, workflows, and abstractions that a platform team builds so that product engineers can ship software without becoming infrastructure experts. It's the difference between a developer asking "how do I deploy this?" and just running ship.
This is different from DevOps in the original sense. DevOps was about breaking down silos between dev and ops — the cultural shift where developers owned their services in production. Platform engineering is what happens when that model scales. You can't have every developer deeply understand Kubernetes scheduling, Terraform state management, and PagerDuty routing. At some team size, that expectation creates a ceiling on velocity. The platform team exists to lower that ceiling — or rather, to raise the floor.
A platform is a product. Its customers are internal developers. If they don't use it voluntarily, you've built the wrong thing.
This framing matters because it changes how you build. A platform nobody uses — because it's too opinionated, too slow, or requires too much ceremony — is worse than no platform at all. It creates a shadow ecosystem of workarounds that you now have to maintain alongside the official tooling.
The Core Components
Every mature IDP I've seen has a few consistent elements, though the specific tools vary considerably by organization:
Self-Service Infrastructure Provisioning
Developers need databases, queues, storage buckets, and environment variables. In most organizations, getting these requires opening a ticket to the infra team and waiting. In organizations with a mature IDP, a developer fills out a form in the developer portal, a Terraform module runs, and the resource is provisioned and wired into the service within minutes — with all the compliance guardrails already baked in.
Tools like Backstage provide the portal layer. Crossplane or Terraform can handle the provisioning backend. The platform team writes the modules once; product engineers consume them without needing to understand what's underneath.
Golden Paths for Service Creation
"Golden path" is the term for a recommended, opinionated way to do something that works well for most cases. When a developer creates a new service through the IDP, they should get:
- A repository scaffolded with your standard project structure
- A CI pipeline already configured
- Kubernetes manifests for dev, staging, and production
- Service-level objectives defined in your monitoring system
- A runbook template
- Log aggregation and distributed tracing already wired in
None of this requires the developer to make infrastructure decisions. It follows the golden path. They can deviate from it — golden paths aren't mandatory — but the path of least resistance leads to a correctly-structured, observable, deployable service.
A Service Catalog
At 30+ services, nobody knows what everything does or who owns it. A service catalog solves this. Each service entry contains its owner, its upstream and downstream dependencies, its SLOs, its on-call rotation, and links to its runbook and repository. When an incident happens at 2 AM and you need to know who owns the payment processing service and what it depends on, the catalog is where you look.
Backstage's Software Catalog is the most common implementation here, with service metadata stored in catalog-info.yaml files alongside the code itself.
Automated Compliance and Policy Enforcement
This is the component that pays for itself the fastest in regulated environments. When every service created through the IDP automatically gets vulnerability scanning, dependency license checking, and IAM guardrails applied, compliance stops being a gate at the end of the development process and becomes a property of the process itself.
When You Actually Need One
Building a platform before you need one is expensive waste. You're creating abstractions to solve problems that don't exist yet, maintained by engineers who could be shipping product. The right time to start investing seriously in platform engineering is when you can check off several of these:
- Onboarding a new engineer to the point where they can deploy takes more than a week
- Senior engineers are regularly blocked waiting for infra access or reviews
- You have more than 15–20 engineers and more than 10–15 services
- Deployment frequency is declining despite growing headcount
- You've had incidents caused by configuration drift between environments
- Compliance reviews require manual evidence gathering
If you're hitting two or three of these, you're probably already paying the cost of not having a platform. You're just paying it in engineer time rather than in dedicated platform work.
The Build vs. Buy Decision
Backstage (open source, from Spotify) is the dominant player in the developer portal space, and it's genuinely good software. But it's not a turn-key solution — getting a meaningful Backstage deployment running requires real investment, and maintaining it requires ongoing attention. We've seen teams significantly underestimate this.
Commercial alternatives like Cortex, Port, and OpsLevel offer faster time-to-value at the cost of flexibility and per-seat pricing that compounds as you grow. They're worth evaluating seriously if your platform team is small or you need results quickly.
For the CI/CD and provisioning layers, most teams are better served by investing in good GitHub Actions or Cloud Build workflows than in custom tooling. The platform's job there is to write the reusable action workflows and Terraform modules, not to build a custom pipeline engine.
Starting Without a Platform Team
Not every organization can staff a dedicated platform team. That's fine — platform engineering is a practice, not an org chart structure. A working model for smaller organizations is to designate a rotating "platform week" where one or two engineers work on internal tooling. The output is a backlog of platform improvements that accumulate over time into something genuinely useful.
The critical constraint is that platform work needs to be protected from product pressures. If it competes directly with feature work in every sprint, it will always lose. Even a small, consistent allocation of engineering time toward developer experience compounds significantly over 12–18 months.
What Success Looks Like
The best measurement of platform engineering ROI is DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service. These are lagging indicators, but they're the ones that matter for business outcomes, and a well-built IDP moves all four in the right direction.
The leading indicator you can watch in real time is developer survey scores on the question: "How easy is it to deploy your service to production?" If that number is going up, the platform is working. If it's flat or declining, the platform is solving the wrong problems.
The teams that do this well treat their internal developers as genuinely as they'd treat external product customers. They run office hours, they collect feedback, they deprecate things that nobody uses. The platform that earns voluntary adoption earns everything.
The Bottom Line
Platform engineering isn't a trend or a title rename — it's an organizational response to a real scaling problem. At small team sizes, the overhead isn't worth it. At medium and large team sizes, the cost of not having it is real and compounding.
If your engineers are spending significant time on infrastructure ceremony rather than building product, the question isn't whether you need a platform. It's whether you've been paying the cost long enough to justify starting now.
The answer is almost always yes.