Most platform teams are funded as a cost. They are a line item: headcount, licences, the internal tooling budget. When money is tight, that line gets questioned, because a cost centre is the first thing an organisation looks at when it wants to look thriftier.

This is the wrong unit of account.

A platform team is not mainly a cost. It is a price change. It changes what every other team pays, in time and risk, to ship a safe change to production. Get that right and the platform stops being something you can afford or not afford. It becomes part of how the business makes money.

Platform teams are not exotic anymore. Gartner expects 80% of software engineering organisations to have established platform teams by 2026. So the question is no longer whether to have one. It is how to justify what it costs, and most organisations are answering in the wrong currency.

I have argued before that platform value is usually measured in the wrong place. This is the same argument pushed up a level, into the language the people holding the budget actually use.

The question leadership asks, and the better one

The question a CFO asks about a platform team is reasonable: what does it cost us?

The better question is: what does it change the cost of?

Every change to a production system has two prices. There is the cost of making the change, writing the code, the obvious part. And there is the cost of making it safely: the testing, the review, the deployment, the rollback plan, the observability, the coordination with everyone the change might break. For anything that matters, the second price is far larger than the first.

The first price is what people picture when they picture engineering. The second is where the money actually goes.

A platform team's job is to drive down the second price. Not for one change. For every change, by every team, for as long as the platform exists.

Marginal cost is the whole argument

Here is the economic idea, stated plainly. A platform is a fixed cost that lowers a marginal one.

You pay for the platform once, and keep paying to maintain it. That is the fixed cost. In return, the marginal cost of the next safe deployment goes down: the next service that needs provisioning, the next team that needs a paved road to production, the next security control nobody has to reinvent.

This is the same shape as any capital investment. You build a factory so that each unit afterwards is cheaper to produce. Nobody asks whether the factory pays for itself in the first week. They ask what it does to unit economics over its life.

Software has unit economics too. The unit is a safe change. Most organisations have never measured what one costs them, which is exactly why the platform that lowers it is so easy to underfund.

And the leverage compounds. The more change flows through the platform, the more the fixed cost is spread, and the cheaper each unit becomes. A platform used by three teams is an expensive hobby. The same platform used by thirty is infrastructure.

What the platform actually prices

It helps to be specific about which costs a platform moves, because "developer productivity" is too vague to put in front of a board.

The cost of the second time. The first team to need a deployment pipeline, a secrets manager, or an audit trail has to solve it. Without a platform, the second team solves it again, slightly differently, and the third team solves it a third way. A platform pays for the solution once and rents it to everyone after. The saving is not the build. It is the builds that never happen.

The cost of coordination. Most of what slows a large engineering organisation is not typing. It is the meeting before the change, the ticket to another team, the wait for an environment, the approval sitting in someone's inbox. A good platform turns coordination into self-service. Self-service is cheaper than a conversation, and it does not sleep.

The cost of a mistake. A change that takes down production is expensive in ways that rarely reach the platform's budget line: the incident, the lost revenue, the trust, the weekend. A platform that makes the safe path the easy path lowers the rate of expensive mistakes. That is an insurance premium paid in advance, and it is cheaper than the claim.

None of these show up as platform revenue. All of them show up somewhere, usually smeared across every other team's costs, where nobody can see the total.

The cost of not having one does not disappear

This is the part leadership consistently misreads. Cutting the platform does not remove its cost. It redistributes it.

The work the platform was doing still has to be done. Provisioning, securing, deploying, observing, recovering. Without a central place to do it, each team does it themselves, badly and repeatedly, in between the work they were actually hired for. The cost moves off the platform's line and onto everyone else's, where it is larger and invisible. Invisible cost is the most expensive kind, because you cannot manage what you refuse to name.

This is the tiny teams, heavy systems point seen from the balance sheet. A small team can move fast only because a heavy system carries the weight it is not carrying. Remove the system to save money and you have not made the team leaner. You have made it slower and called it a saving.

AI raises the price of getting this wrong

If the platform prices the cost of safe change, then anything that increases the volume of change increases the value of the platform. AI is the largest increase in the volume of change the industry has ever seen.

DORA's 2025 report is blunt about it: AI does not fix a team, it amplifies what is already there, including the quality of the platform underneath it. More generated code, more pull requests, more agents acting across more repositories. Every one of those is a change that has to be made safely. The marginal cost of safe change is now being paid far more often.

When the volume of change goes up, the thing that lowers the cost per change stops being a nicety. It becomes the constraint on whether the volume helps you or buries you. I have made the case that the next phase of AI engineering is boring on purpose: tests, gates, evidence, paved roads. Someone has to build and own that. That someone is the platform team, and AI has just made their work the highest-leverage spend in the organisation.

How to account for it honestly

If a platform is an economic function, it should be measured like one, not with a satisfaction survey.

The honest metrics are about the price of change, not the happiness of developers. How long, and at how much risk, does a change get from merged to production? How much of that is self-service versus waiting on a human? How often does the safe path fail and force someone onto an unsafe one? What is the rate of expensive mistakes, and is it falling? How many teams are on the paved road, and how many have worn a goat track around it because the road did not fit?

Adoption is the one that matters most, because it is the closest thing to revenue a platform has. A platform nobody uses has a marginal cost of zero changes, which means its fixed cost buys nothing. This is why the best platform teams behave like product teams chasing adoption, not like an internal authority issuing standards. A standard nobody adopts is a cost with no offsetting price change.

The reframe

The platform team is usually defended in the wrong language. Faster developers, better tooling, happier engineers. All true, all easy to cut, because none of it sounds like money.

The accurate defence is economic. A platform team changes the marginal cost of safe change. It is a fixed investment that lowers a recurring price every other team pays. It gets cheaper per unit the more it is used. And the cost it carries does not vanish when you cut it. It just moves somewhere you can no longer see.

Fund it as a cost and you will always be tempted to trim it. Fund it as what it is, the thing that sets the price of shipping software safely, and the question changes from "can we afford the platform?" to "can we afford what we pay without it?"

Most organisations have never run that second number. The ones that do tend to stop asking the first.