> ## Content Index > Fetch the complete content index at: https://chadkar.com/llms.txt > Use this file to discover other available public pages before exploring further. # Who counts the value a platform creates - URL: https://chadkar.com/platform-cost-and-who-counts-the-value/ - Published: 2026-09-05T06:25:00.000Z - Updated: 2026-09-06T07:38:22.000Z - Description: A shared platform carries its cost in one budget and delivers its value into other people's numbers. Deciding who books that benefit, before anything ships, is the whole argument. - Author: Chad Karannagoda - Tags: Product Leadership, Platforms and Operating Models There is a point where an internal platform stops being a project and becomes a line item that somebody has to defend every year. Nobody announces it. You notice it the first time you are asked what the thing costs and you realise the honest answer is longer than the question. Most of the writing about platforms is about building them. Very little of it is about paying for them, which is strange, because the paying is where most of them quietly die. ## The asymmetry that makes this hard A shared platform has a cost profile that is easy to see and a value profile that is almost impossible to see from the same place. The cost is concentrated. It lands in one budget, under one owner, in a number that goes up every quarter as more people use the thing. The value is diffuse. It shows up as a use case that got to production faster, a team that did not have to build its own infrastructure, a control conversation that took two weeks instead of two months. Every one of those lands somewhere else, in somebody else's numbers, attributed to somebody else's initiative. So the platform accumulates all of the visible cost and almost none of the visible credit. Left alone, that arithmetic ends only one way. ![One platform budget box carrying all of the cost, with arrows out to three business areas where the benefit lands](https://chadkar.com/content/images/2026/09/dia-pc-v2.svg) ## Non-production is not free, and it is not small The first surprise for most people is how much of the bill is not production. Development and test environments, the capacity that sits ready rather than working, the second region, the duplicate of everything that exists so that a change can be proven before it is real. None of that serves a customer. All of it is the cost of being allowed to move safely, which is a real thing to be buying, and it needs to be named as such rather than buried. If you cannot explain why the non-production line exists, someone will eventually decide it does not need to. ## Adoption changes the shape of the curve, not just the size of it The first team onto a platform is enormously expensive. They pay for the platform's existence. The second is cheaper. By the tenth, the marginal cost of another team is close to nothing, and the whole investment case turns on getting to that point. Which is why onboarding is not an operations concern. It is the mechanism that converts a fixed cost into a shared one. A platform that is hard to join stays expensive per user forever, and the number it produces at budget time is indefensible for reasons that have nothing to do with the technology. ## Generative AI inverts the arithmetic Traditional machine learning platform cost is broadly a function of how much capability you keep standing up. Add a team, add some infrastructure, and the curve flattens as reuse improves. Generative AI does not behave like that. Inference cost scales with use. A successful use case, one that people genuinely adopt, costs more the more it succeeds, and it keeps costing more indefinitely. The better it works, the larger the bill. That breaks a habit everyone in this position has learned, which is to treat adoption as unambiguously good news. It is still good news, but it is no longer free news, and the forecast has to say so before it happens rather than after. Being the person who explained the shape of that curve in advance is a very different position from being the person explaining an overrun. ## Getting value counted where it lands The hardest part of this is not the modelling. It is agreeing, before anything ships, who books the benefit. If a platform makes a business area's use case possible, the value shows up in that business area. That is correct and it should stay that way. But if nobody has agreed in advance that the platform gets to point at it, then at review time the platform has a cost and no benefits, and the business area has benefits that appear to have arrived on their own. This is not an accounting curiosity. It decides whether the platform is understood as infrastructure that pays for itself several times over or as an expensive internal hobby. The conversation is unglamorous, it happens with finance and with business owners rather than with engineers, and avoiding it is the single most common way capable platform teams get themselves defunded. ## What this means for the work It means the roadmap is a funding argument whether or not you intended it to be. Every sequencing decision is also a statement about what the organisation should be paying for and when. It also means the skill is not forecasting. Anyone can build a forecast. The skill is being able to hold a defensible position on why the number is what it is, what would make it larger, what would make it smaller, and what the organisation gets in return, in language that survives contact with people who do not care how any of it works. You do not get to opt out of that by being technical. If you own the platform, you own the argument for its existence. ## What this does not cover This is about internal shared platforms inside large organisations, where the consumers are other teams and there is no revenue line. A product with external customers and a price has a different and considerably easier problem, because the value arrives in the same currency as the cost. Very little of the above transfers cleanly to that situation, and I would not try to make it. ## References - [FinOps Foundation, "The FinOps Framework"](https://www.finops.org/framework/). The standard vocabulary for cost allocation, showback and forecasting, which is what the argument about who books the benefit becomes once finance is in the room - [Evan Bottcher, "What I Talk About When I Talk About Platforms"](https://martinfowler.com/articles/talk-about-platforms.html). 2018\. The case for an internal platform as a product that has to be compelling rather than mandated, which is what makes adoption a funding question rather than a communications one ## Related - [The Platform Responsibility Line](https://chadkar.com/platform-responsibility-line/) - [Improving platform onboarding as a product problem](https://chadkar.com/platform-onboarding-as-a-product-problem/) - [Decision Under Constraint](https://chadkar.com/decision-under-constraint/)