Platform engineering is having its moment, and with it comes pressure to build an Internal Developer Platform because everyone else seems to be. Some teams genuinely need one this quarter. Others would burn six months building a portal nobody uses. Here is the framework we use to tell the difference.
The three signals you need an IDP now
- Ticket-ops: developers wait days for environments, databases or access because a central team provisions by hand. If your infra team is a ticket queue, you have an IDP-shaped hole.
- Snowflake sprawl: no two services deploy the same way. Every team has its own pipeline conventions, IaC style and secrets approach — and every incident starts with archaeology.
- Onboarding drag: a new engineer takes weeks to ship their first change because the path from laptop to production exists only in tribal knowledge.
Two or more of these at a team size above roughly 20 engineers is the threshold where a platform investment pays back within quarters, not years.
When to wait
Under 15 engineers, a well-maintained module library and a paved-road CI/CD template deliver 80% of the value at 10% of the cost. An IDP is a product; products need users, a roadmap and an owner. If you cannot name who will own the platform in 12 months, you are not ready to build it.
The minimum viable platform
The IDP initiatives that survive start embarrassingly small: one golden path for the most common service archetype, self-service environment vending with guardrails baked in, and a catalog so people can find what exists. Backstage is the default choice for the portal layer, but the portal is the last 10% — the real platform is the module library, the vending automation and the guardrails underneath.
- A versioned Terraform/Bicep module library with CI validation and semantic releases
- One golden-path template: repo, pipeline, infra, observability and security defaults in one scaffold
- Self-service environment creation with cost tags, budgets and TTLs enforced at vend time
- A thin catalog/portal layer only after the paths above are proven
The mistakes that kill IDP initiatives
- 01Building the portal first. A beautiful Backstage instance over manual provisioning is a brochure, not a platform.
- 02Mandating adoption. Platforms win by being the easiest path, not the required one. If teams route around your platform, the platform is the problem.
- 03No product owner. Platforms without a roadmap and a feedback loop rot into legacy within a year.
- 04Boiling the ocean. Supporting every language, every archetype and every cloud on day one guarantees you ship nothing usable this year.
What good looks like after two quarters
Environment lead time drops from weeks to under an hour. New services start from the golden path by default because it is genuinely faster. The infra team stops being a queue and starts being a product team. Those are the metrics worth reporting to leadership — not portal page views.
If you are weighing this decision, our free platform audit includes an IDP readiness assessment: where you sit against the signals above, and whether a module library, a golden path or a full platform is the right next step for your team size and stage.