What Is an Internal Developer Platform (IDP) and Does Your Company Need One

Q: "What is an internal developer platform IDP"

"An internal developer platform (IDP) is a self-service layer built on top of your infrastructure that lets engineers deploy, monitor, and manage applications without needing to understand the underlying cloud or Kubernetes configuration. Companies like Spotify (Backstage) built their own; most companies at under 200 engineers are better served by a simpler version."

An internal developer platform (IDP) is a self-service layer that sits on top of your infrastructure and lets engineers deploy, monitor, and manage their applications without needing to understand the underlying cloud configuration, Kubernetes manifests, or infrastructure-as-code templates. The developer says “deploy my service to staging,” and the platform handles the rest.

Why It Exists

As organizations scale, the gap between “I wrote the code” and “it’s running in production” widens. A developer at a 200-person engineering org shouldn’t need to understand Kubernetes networking, Terraform state files, and cloud IAM policies just to ship a feature. That’s where the IDP comes in — it abstracts away the infrastructure complexity behind a self-service interface.

Spotify popularized the concept with Backstage, their open-source developer portal that became a CNCF project. But Spotify had 2,000+ engineers and a genuine problem of infrastructure sprawl. The question isn’t whether IDPs are useful — it’s whether your company has the problem they solve.

What an IDP Actually Includes

A typical IDP has some combination of: a service catalog (what services exist, who owns them, what they depend on), a deployment interface (push-button deployment without editing pipeline configs), environment provisioning (spin up a staging environment without filing an infrastructure ticket), and an observability layer (logs, metrics, and traces accessible from one place).

The more sophisticated versions add golden path templates (start a new service from an opinionated template with CI/CD, monitoring, and security scanning pre-configured), developer documentation aggregation, and cost visibility per service.

Who Needs One (And Who Doesn’t)

Under 50 engineers: you almost certainly don’t need a full IDP. You need a well-documented deployment process, a template repository, and maybe a simple internal wiki. The overhead of building and maintaining an IDP exceeds the time it saves at this scale.

At 50-200 engineers: you might need pieces of an IDP — a service catalog, standardized deployment templates, self-service environment creation. Don’t build a portal. Build the specific capabilities that address your specific bottlenecks.

At 200+ engineers: a proper IDP starts making economic sense. At this scale, developer onboarding time, service discoverability, and infrastructure self-service directly impact engineering velocity. The platform team can justify itself through measurable improvements in time-to-deploy and onboarding speed.

Common Mistakes

Building a portal nobody asked for. I’ve watched companies spend six months building an internal Backstage instance because a conference talk inspired them. Nobody used it because the 30 engineers on the team were perfectly fine with their existing workflow. Start with the problem, not the tool.

Adopting Backstage because it’s open source. Backstage is free to download. It is not free to operate. It requires dedicated engineering time to build plugins, maintain integrations, and keep it useful. For smaller teams, the maintenance burden often exceeds the value.

Confusing an IDP with a CI/CD pipeline. Your CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins) is one component of an IDP, not the whole thing. An IDP is the abstraction layer above the pipeline — the thing that makes the pipeline invisible to application developers.

Over-abstracting too early. The best IDPs evolve from solving real problems. The worst ones are designed top-down by a platform architect who imagined what developers might need. Start with the pain points. Build the minimum abstraction that addresses them. Expand from there.

The Verdict

IDPs are a genuinely useful concept for large engineering organizations. But the industry has a pattern of taking things that work at Spotify/Google/Netflix scale and selling them to 30-person engineering teams. If you’re under 200 engineers, focus on the fundamentals — good CI/CD, clear deployment documentation, and a standard way to create new services. Call it an IDP if you want, but don’t build a portal.