Sometimes the Missing Layer Should Stay Missing

I’ve now written two articles arguing that data organizations need an Internal Developer Platform: one on why the layer is missing, one on the organizational forces that kill it after you build it. Both contained a short “when this doesn’t apply” section, and I’ve come to think that section deserves to be an article of its own. Partly for symmetry, and partly because the most expensive platform failures I’ve seen weren’t badly built platforms. They were platforms that should never have been started.

So this is the third act, and it’s the honest one: the cases where building an IDP destroys value, how to recognize them from the inside, and the ladder of cheaper things that gets you most of the benefit.

A platform is a fixed cost, and fixed costs don’t scale down

The core economics are simple and mostly ignored. A platform team’s cost is roughly fixed: the effort to build and maintain golden paths, scaffolding, and self-service infrastructure doesn’t shrink much just because fewer people use it. The benefit, meanwhile, scales with the number of teams consuming it. Small denominator, terrible ratio.

Put numbers on it. Practitioner rules of thumb put a platform team at 5 to 10 percent of total engineering headcount. At 400 engineers that’s a solid team amortized across dozens of delivery teams. At 40 engineers it’s two to four of your best people not building product, serving maybe five teams. If you go the popular route and self-host Backstage, the total cost gets uncomfortably concrete: organizations satisfied with their deployment dedicate three to twelve full-time engineers to it, with a first-year cost around three quarters of a million dollars (a vendor’s estimate, but the headcount range matches what I hear from teams running it). Recall from the previous article that nearly half of real platform teams operate on budgets under one million dollars in total. For a mid-size organization, a self-hosted portal can quietly consume the entire platform budget before a single golden path exists.

Will Larson’s rule for infrastructure investment applies with full force here: if you don’t pick problems well, a well-run company will destaff your team. A platform built ahead of demonstrated demand is exactly the kind of problem-picking that ends in destaffing.

The failure is not hypothetical, and it’s not rare

A case study made the rounds this month that I’d make required reading for anyone about to write an IDP business case. A roughly 40-engineer organization spent six months and four senior engineers building a Backstage-based platform under executive mandate. Launch week: 140 users. Three months later: 28 unique users, most of them the platform team itself. The team eventually retired the portal and replaced it with a command-line tool and some automation. Time from service creation to deployment dropped from three weeks to twelve minutes. The expensive part wasn’t the failed portal; it was discovering that what developers actually wanted was a good CLI, six months and four engineers too late.

The pattern generalizes. DORA’s 2024 research found platform adopters saw individual productivity gains alongside 8 percent lower throughput and 14 percent lower change stability. A 2026 peer-reviewed literature review of 88 platform engineering sources concluded that organizations “frequently over-engineer platforms before validating developer needs, violating the thinnest viable platform principle”, and noted, usefully, that most of the pro-IDP evidence base is vendor-produced. The people telling you every organization needs a platform are, overwhelmingly, people selling platforms.

The test is repetition and cognitive load, not ambition

So how do you tell which side of the line you’re on? Not by org chart envy, and not by conference talks. Two published decision rules cover most of it.

The first is the Team Topologies criterion: a platform team exists to reduce the cognitive load of stream-aligned teams. Not to standardize for its own sake, not to give infrastructure people a product to own. If your delivery teams aren’t visibly drowning in infrastructure decisions they shouldn’t have to make, there’s no load to relieve, and a platform is a solution renting office space while it looks for a problem.

The second is the break-even test, stated cleanly by Schaatsbergen and ter Beke: add a platform layer only when the energy teams collectively waste on duplicated work exceeds the energy a platform team would spend providing it centrally. In the first article I offered a small version of the same test: are your teams solving the same infrastructure problem independently, more than twice? Jeff Atwood’s old rule of three says reusable components cost three times as much as single-use ones, so you want three real, existing consumers before you generalize anything. Three data teams that have each hand-built the same deployment pipeline is a platform signal. One team that might need it next year is not.

If you run both tests and they come back negative, the answer isn’t “do nothing.” It’s a ladder, and each rung is dramatically cheaper than the one above it.

A wiki page is a legitimate platform

Start with the observation Matthew Skelton has been making since 2019, which the industry keeps refusing to hear. The Thinnest Viable Platform can literally be a wiki page: we use this cloud, these services from it, in this way. His words: “if that’s all you need, don’t build anything else; you’re still running on a platform, you just don’t make it any thicker than necessary.” The Team Topologies authors even publish a template repo for the wiki page. It’s a contract, not software: what’s supported, who to ask, what the defaults are.

This sounds too cheap to work until you remember where golden paths came from. Spotify’s original Golden Path, the ancestor of all of this, was a tutorial: a step-by-step document describing the recommended way to build a service, written to kill what they called rumour-driven development. The company that gave the world Backstage started with documentation. Pair the wiki page with Architecture Decision Records so the “why” survives staff turnover, and you have a platform whose total cost is the time it takes to write things down.

Templates capture most of a blueprint at a fraction of the cost

The single highest-leverage rung for data teams. Most of what I described in the first article as a blueprint (standard project structure, naming conventions, quality checks, CI/CD wiring) can live in a Cookiecutter or copier template with no runtime platform behind it. The classic objection is drift: generated projects diverge from the template the day after creation. That’s a solved problem; cruft records which template commit a project came from and re-applies upstream template changes as diffs.

The evidence this works at data-team scale is concrete: one consultancy went from zero to over 150 standardized dbt projects in under a year on Cookiecutter and cruft alone, with engineers running dbt against a client within minutes of project creation. And the vendors are eating this rung from below: Databricks now ships bundle templates (default Python ETL, dbt, MLOps stacks) plus support for custom organizational templates, which means a data platform lead can encode standards into scaffolding the vendor maintains the machinery for.

Paved roads don’t need portals

The next rung up is shared, versioned automation: reusable CI/CD workflows consumed by every repo, and Terraform modules treated as products, where “how a data pipeline runs here” is defined once with monitoring and access baked in. This is most of what an IDP does, minus the user interface, and the user interface is the part teams overvalue most. GitLab’s field CTO put it better than I can: without real platform capabilities underneath, a portal “merely presents a unified view of dysfunction”. The 40-engineer team from the case study rebuilt their entire developer experience as a CLI on top of exactly this rung. Developers live in terminals and editors; a browser tab is not a prerequisite for self-service.

An enabling team before a platform team

If the pain is real but diffuse, the right first hire isn’t a platform team; it’s what Team Topologies calls an enabling team: a few experienced engineers who embed with delivery teams and teach, rather than build. Manuel Pais is explicit about the sequencing: start by doing enabling work, because being on the ground with teams tells you what your actual customer needs are before you commit to a platform backlog. The enabling team is also your cheapest research program: after two quarters of embedding, either a platform backlog has written itself from repeated observations, or you’ve learned that the problems were too varied to platform away. Both outcomes are worth more than a portal.

Buy the boring layer

The last rung: aggressively refuse to build anything a vendor will run for you. Charity Majors calls the principle Run Less Software; Adrian Cockcroft describes how Netflix deliberately wanted AWS to “eat away at the bottom” of its thin custom platform layer year after year. For application teams in 2026 the managed options are genuinely good. For data teams, much of what required a custom platform five years ago is now native: managed orchestration, serverless compute, catalog and lineage, scaffolding templates. The honest counterpoint comes from Christopher Hedley: “you cannot buy what only you need”; genuinely differentiating workflows won’t come off the shelf. But that argument cuts the way vendors don’t want it to: buy everything undifferentiated, and keep the layer you build so thin that a wiki page and some templates might be all of it.

When to climb back up

None of this is an argument that platforms are wrong; it’s an argument about sequencing. The ladder itself tells you when you’ve outgrown it. When the template repo’s pull request queue becomes a bottleneck, when the enabling team keeps writing the same runbook for the fourth team, when the break-even test flips because ten teams are duplicating the energy of two platform engineers: that’s the demand signal a platform should be built on. And a platform built then starts life with everything the failed ones lacked: known customers, a validated backlog, and adoption pull instead of a mandate. The CNCF maturity model makes the same point from the other direction: its lowest investment level (voluntary, part-time, no central funding) is a legitimate place to be, and “reaching the highest level should not be a goal in itself.”

When this doesn’t apply

If you’re the organization from the first article (many data teams, dozens of data products a year, compliance evidence demanded at scale) then the ladder is where you already were, and it stopped being enough; build the platform, and read the second article before you do. This piece is for everyone who isn’t there yet and is being told, mostly by people with something to sell, that they’re behind.

Where this leaves us

Skelton’s framing deserves the last word, because it dissolves the false question. You don’t decide whether to have a platform; you already have one, assembled from your cloud provider, your CI system, and your team’s habits. The only decision is how thick to make it. Thickness is bought with your scarcest people and repaid only by scale you may not have. So keep the platform as thin as your organization allows. If you can still coordinate by conversation, the conversation is the platform, and it’s the only one I know of that maintains itself.