
[Gartner predicted](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering) 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](https://www.cncf.io/announcements/2026/03/25/cncf-backstage-documentary-highlights-project-evolution-from-development-to-global-open-source-standard-for-platform-engineering/). 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](https://platformcon.com/) 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](/cloud/rethinking-infrastructure), where this argument started.
More about what we're building at [light-cloud.com](https://light-cloud.com).


The platform should be a product, not a headcount line

Every Company Is Building the Same Internal Platform, Badly


On July 23, 2021, Cloudflare's CEO co-signed a blog post with a spreadsheet in it. [AWS's Egregious Egress](https://blog.cloudflare.com/aws-egregious-egress/) estimated that AWS was charging US and Canadian customers roughly 80 times its own bandwidth cost, with markups in some regions approaching 8,000%. AWS never published the rebuttal that would have settled it, the one with its actual costs in a table. It didn't need to. Egress pricing wasn't an error anyone had to defend; it was a mechanism doing its job.

So here's the thesis, stated flat: cloud pricing complexity is a business model. The bill nobody can predict and the bandwidth charge that only applies in one direction aren't accidents of a complicated product. They're structural incentives, built by smart people, working as intended. Treating them as accidents is how you lose to them.

## The one-way valve

Data transfer into a hyperscaler is free. Transfer out is metered. A pipe that's free inbound and expensive outbound isn't a pipe, it's a valve, and the valve has a compounding property: every gigabyte you store raises the cost of ever leaving. Egress was never priced as bandwidth. It's an exit tariff that grows with your own success.

Watch what happened when the tariff met regulation. Within nine weeks in early 2024, [Google (January 11), AWS (March 5), and Microsoft (March 13)](https://kempitlaw.com/insights/the-end-of-switching-charges-commercial-impact-and-compliance-priorities/) all announced free data transfer out for customers leaving their platforms entirely, each framed as generosity rather than compliance. The trigger was the EU Data Act, which caps switching charges at direct cost today and bans them outright on January 12, 2027. Costs didn't change that quarter. Law did. A price that survives well over a decade and dies only when regulators kill it was strategy all along.

And read the fine print: only the final exit got free. The meter on ordinary operational egress, the kind you pay every month while staying, runs exactly as before.

## A discount you need a trading desk for

On-demand is the sticker price almost nobody pays at scale. The real prices sit behind reserved instances and savings plans: one-year and three-year commitments, partially or fully prepaid, with discounts deep enough that refusing them looks irresponsible in any budget review. That's a forward contract on compute. AWS even operates a [Reserved Instance Marketplace](https://aws.amazon.com/ec2/purchasing-options/reserved-instances/marketplace/) where customers resell commitments they mis-sized, and the moment your discount program needs a secondary market, it has stopped being a discount program.

An entire profession formed around reading the bill. The [FinOps Foundation](https://www.finops.org/) runs certifications and an annual conference for the discipline of understanding what you're paying for. Sit with that. Your office electricity bill doesn't support a career track.

The commitment machine's subtlest effect is political: once three years of spend are prepaid, your CFO becomes the cloud's advocate inside your own company, because every workload that might move somewhere better is now a workload that strands committed dollars. Lock-in enforced by your own finance department costs the vendor nothing. The discount is the moat.

## Complexity as a sorting machine

Every dimension a bill gains makes it harder to predict and easier to segment. Per-request pricing here, per-GB-month there, a separate rate for traffic that crosses an availability zone boundary, and an hourly charge for the NAT gateway somebody enabled years ago that everyone since has been afraid to touch. Classic price discrimination requires the seller to learn each buyer's willingness to pay. A sufficiently complex price sheet does it automatically: buyers with FinOps staff excavate the discounts, and everyone else pays sticker.

The [$4,847 bill](/startup/cloud-bill-horror-story) that started this company, for an app serving 10,000 requests a day, wasn't a malfunction. It was the machine sorting. Light Cloud exists because that bill landed in the tier reserved for people who don't employ someone to fight it. The pricing pages are all public, and still nobody can compute their own invoice from them; both facts are stable, and the second one is the point.

## The honest defense

The strongest counterargument deserves stating properly: cloud pricing is complex because the underlying costs are complex. Hardware differs by region, power costs swing with local grids, and metering usage at fine granularity is exactly the thing that lets a hobby project cost pennies a month instead of a license fee. Usage-based pricing is also fairer than the per-core licensing world it replaced, where you paid the same whether the server idled or burned. All of that is true, and I'll concede more: nobody designed this in one villainous meeting. It accreted, one reasonable-looking SKU at a time.

But complex costs don't force complex prices. Utilities face brutally variable input costs and still sell flat tariffs, because absorbing pricing risk is part of the product a utility sells, and hyperscaler margins leave plenty of room to hedge internally. The tell is where the complexity clusters: thick around the places where switching decisions happen, like egress and long-term commitments, and thin where they don't. Accidental complexity would be evenly distributed. This isn't.

This is why Light Cloud prices the way it does. Usage-based, scaling to zero when nothing runs, with a pricing page meant to be computable by one person with a napkin; if you can't predict your bill from it, we treat that as our bug rather than your homework.

A two-person company keeping pricing simple proves little, and I know it; simplicity is cheap when you're small. The commitment is about direction. Complexity added to a pricing page becomes revenue somebody defends later, so the discipline is refusing the first SKU we can't explain in one sentence.

Next time a cloud bill surprises you, don't ask what you did wrong. Ask which mechanism found you: the valve, the commitment, or the sorter. Then ask the sharper question: which one is your architecture feeding right now?

---

Related: [Cloud Pricing That Makes Sense](/cloud/cloud-pricing-that-makes-sense), where I laid out our own model.
More about what we're building at [light-cloud.com](https://light-cloud.com).


Industry

Every Company Is Building the Same Internal Platform, Badly

Cloud Pricing Complexity Is a Business Model, Not an Accident