Every second engineering leader we talk to is being pitched an internal developer platform. Backstage demos look great. The promise (self-service infrastructure, golden paths, developers who never file a ticket) is real. But so is the failure mode: a platform team of five maintaining a portal nobody logs into.
The test: do you have repeated paved-road decisions?
An IDP earns its keep when the same infrastructure decision gets made over and over, slightly differently each time. New service? Someone copies a neighboring repo, edits a pipeline they don't understand, and asks in Slack which IAM role to use. If that happens weekly, you have platform demand. If it happens quarterly, you have a documentation problem.
Our rule of thumb before any platform build:
- Fewer than ~30 engineers: you don't need a platform, you need three good templates and a README that isn't lying.
- 30–100 engineers: you need golden paths. Service templates, a standard pipeline, one blessed way to get a database. A portal, probably not.
- 100+ engineers, multiple product lines: now the coordination cost is real, and a thin IDP can pay for itself.
Start with the paved road, not the portal
The most common mistake is starting with the UI. A portal is the last layer. The order that works:
- Standardize the artifact: one service template with CI, observability, and deployment wired in.
- Make provisioning declarative: infrastructure requests as pull requests against a Terraform or Crossplane repo, reviewed by CODEOWNERS.
- Only then, if ticket volume justifies it, put a portal in front.
A team that ships a great template gets 80% of the IDP value for 5% of the cost:
# service.yaml: the entire "platform interface" for most teams
name: payments-reconciler
template: go-service@v3
tier: 2
database: postgres-small
alerts:
owner: "#team-payments"
The question that settles it
Ask your engineers: "What's the last infrastructure thing you waited on?" If the answers cluster around the same two or three requests, automate those requests and stop. If the answers are all different, no platform will save you; the inconsistency upstream is the real problem, and that's an architecture conversation, not a tooling one.
We've talked clients out of IDP builds more often than into them. The ones who did build one had the boring prerequisites in place: stable service shapes, a funded platform team with a product mindset, and executive patience measured in quarters. If any of those is missing, fix that first. The portal can wait.