Every Company Is Building the Same Internal Platform, Badly

Gartner predicted that by 2026, 80% of large software engineering organizations would run platform engineering teams, up from 45% in 2022. It's 2026, and from where I sit the prediction landed. Ask around: there's a platform team in your company, and it's building a service catalog, golden-path templates, pipeline glue, a secrets story, per-branch preview environments, and a cost dashboard. So is the platform team at the company across the street. Same spec, same parts, no shared code.

My claim is blunt: nearly every company is building the same internal platform, most are building it badly, and the root cause is a category error. The platform gets treated as a headcount line when it's actually a product, and products built without customers who can say no come out bad.

The same portal, hand-rolled

Spotify open-sourced Backstage in 2020 and donated it to the CNCF, where it has since been adopted by more than 3,400 companies. That number is the tell. Thousands of organizations looked at their internal tooling problem and picked the identical answer, which confirms the problem is common rather than special. But Backstage is a framework, a very good one, and a framework is homework. You staff engineers to assemble your portal from it: writing catalog-info.yaml files for every service, carrying plugins through API churn, wiring your auth, and chasing a catalog that drifts stale the week after launch. The industry's response to "everyone builds the same thing" was a kit for building the same thing.

The category even has its own conference circuit. PlatformCon fills its schedule with talks on golden paths and developer experience, and you could swap the company names between most of the slide decks without anyone noticing. An industry event where everyone describes building the same software is a strange kind of proof that it should be software you can buy.

A product with no market pressure

An internal platform has captive customers. Nobody can churn. Without churn there's no signal that onboarding is broken, and with adoption arriving by mandate, nothing ever tests whether a single engineer would choose the thing voluntarily. The roadmap gets set by whichever team escalates loudest. That's a politics engine sitting where a market should be.

The metrics compound it. Platform teams get measured on adoption, so the quarterly goal becomes migrating more teams onto the platform, which rewards mandates and onboarding pushes rather than anything a user would describe as better. A vendor lives on retention instead: the product has to keep being chosen, month after month, by people holding a cancel button. Remove the cancel button and you've removed the feedback.

When the platform disappoints, engineers route around it with a Makefile and a cron job running kubectl apply, and the platform team's answer is usually a policy forbidding the workaround, which is a move no commercial vendor could survive making. Then there's the cost accounting nobody performs. A five-engineer platform team is the most expensive software subscription in the company, except it can't be cancelled at renewal, its price rises with every salary review, and it serves exactly one customer, so the economics never improve with scale. Internal software gets none of the scrutiny we'd apply to a vendor invoice a tenth its size.

When building it is right

Spotify had real scale pain; Backstage began life solving service discovery for an organization drowning in microservices, and at that size a dedicated platform is obviously justified. Netflix has talked for years about its Paved Road, and for them the platform genuinely is strategy. Regulated industries need integrations no vendor ships. And a small platform team that mostly glues managed services together, rather than rebuilding them, tends to pay for itself. Timing matters as well: a platform extracted from a product you've already scaled encodes real lessons, while a platform built ahead of scale encodes guesses.

I'll concede one more thing: buying has its own failure mode, the vendor platform so generic it fits nobody and so sticky nobody can admit the purchase failed. Skepticism toward platforms-as-products is earned. The test is differentiation. Write your platform team's current quarter on a whiteboard, then write what you'd guess any other company's platform team is doing this quarter, and if the two lists match, differentiated headcount is being spent on undifferentiated software that vendors and open-source projects are already competing to commoditize. Build what makes your company strange. Buy what makes it the same as everyone else.

Light Cloud is our bet on the product version of this argument. The things platform teams keep hand-rolling are what we sell as boring commodities: deploys from GitHub with a preview environment on every branch, and databases without a database subteam, priced to scale to zero when idle. I'm aware this post argues our own book. Discount for that, and the pattern still stands.

The argument predates the company, though. Platform work expands to fill the headcount allocated to it, because there's always one more integration, and no customer exists to say the next one isn't worth paying for.

So run the audit. List what your platform team shipped last quarter, then search GitHub and a vendor directory for each item, and count how many entries nobody else has built. The count won't be high, and the honest version of the exercise also counts the maintenance hours, because a portal is never shipped, only kept alive. What would those engineers build if the platform were already built?

Related: Rethinking Infrastructure, where this argument started. More about what we're building at light-cloud.com.