Whose unit economics are they actually?

Somewhere in a software business there might be a dashboard labelled unit economics, cost per API call, cost per gigabyte stored, cost per token, built by the FinOps team or a tool vendor, and trusted because it came from the people who manage the cloud bill.

Those numbers used to stay on an engineering screen, they are now arriving in pricing reviews. In 2026 the FinOps Foundation changed its mission (checked 9 November 2026) from advancing the people who manage 'the value of Cloud' to those who manage 'the Value of Technology', and added a capability, Executive Strategy Alignment (checked 9 November 2026), that names cost per token, beside cost to serve, among the unit measures executive decisions should reference. At its most mature stage, the Foundation's FinOps Framework says unit economics shape 'build vs buy, architecture, workload placement, migration, sourcing, and pricing decisions', so whatever sits on that dashboard is now expected to help set a price.

The people who built that dashboard were faithful to what they had, cost arrives from suppliers in the supplier's units, a request to its service, a gigabyte held for a month, a token of text through a model, while the units the business runs on, customers and seats, sit in a billing system the cloud bill has never met. Where did the dashboard's definitions come from? Most of them trace back to the Framework itself, whose Unit Economics capability (checked 9 November 2026) opens its measures with cost per API call and cost per gigabyte stored, and describes its first stage as 'primarily working on technical unit cost metrics which are more concrete and centered on variable cost'. Read that way, the distance between a supplier's meter and a customer looks like a maturity step, something a practice grows into, rather than a piece of work somebody has to do.

The metrics themselves are sound, cost per call is the number an engineering team can actually move, by caching a response or choosing a smaller model, and it is the first unit cost anyone can measure, long before the cloud bill has been joined to a customer list. The practitioner who calls it the first stage of unit economics is describing a real sequence, every practice starts with the data it has, and for a cost practice that data is the supplier's meter, so if being measurable first made a metric unit economics, every business would be run on its suppliers' meters. A platform team that charges the rest of the business per call can fairly price itself per call, it sells calls, the SaaS business above it buys them.

Cost per API call is your supplier's unit economics, not yours.

That is closer to literal than it sounds, what a business pays per call is, discounts and commitments aside, roughly what its supplier earns per call. A unit economic is cost, revenue, or margin expressed against a unit of what a business sells or who it sells to: cost to serve a customer, revenue per seat, margin per transaction, cost per accepted output. It is the test our definition of unit economics already applies, spend against the business activity it supports, made explicit about whose activity counts, and the same test settles what to cut from an AI bill. The test holds the other way round as well, a business that sells API calls has made the call its unit, and for that business cost per call is unit economics.

The two numbers can point in opposite directions in the same quarter, take a product whose API spend rises from $120,000 one quarter to $150,000 the next, while calls rise from 40 million to 60 million and the customer count holds at 2,000.

Cost per call has fallen 17 per cent, cost per customer has risen 25 per cent, because each customer now generates half as many calls again. What the dashboard will report as an efficiency gain is a customer base getting more expensive to serve.

A team that sees this and moves to the business's units has done the right thing, and the Framework's ladder is waiting for it, its second stage is where 'business unit metrics (like cost per customer, cost to serve, or contribution margin) become more trustworthy', and the same stage where 'unit economics begin to account for fully loaded costs'. Contribution margin is what remains after the costs that move with the unit, it excludes allocated fixed cost by definition, so a stage that names it alongside fully loaded cost has put two answers to the same question side by side without saying which one a decision should use.

You get the unit right just as you get the cost wrong.

Take a feature that earns $40,000 a month, carries $22,000 of cost that moves with its use, and is allocated $25,000 of shared platform cost, the clusters and databases every feature runs on. Fully loaded it costs $47,000 and loses $7,000 a month, on contribution, revenue less the cost that moves with the feature, it adds $18,000. Switch it off and the $25,000 stays in the allocation, the allocation lands on the features that remain, and the business is $18,000 a month worse off for a decision its most mature metric recommended.

No stage of the ladder says which cost a decision should use, the first had the right cost on the wrong unit, and at Run, where it says unit economics shape pricing and build-vs-buy decisions, the only cost basis it names is fully loaded, so a team that follows it to the top takes most of those decisions on the wrong cost. Fully loaded cost still has a job, prices have to recover fixed and shared cost over time and fully loaded cost is how a business checks that they do, it is the wrong instrument for a discount, a deal, or one more customer or feature, where only the cost that moves with the decision changes the answer.

Finance settled this long ago, relevant costing treats a cost that stays whatever the decision as irrelevant to it, and any standard management accounting text carries a version of the feature example. ACCA's study article on relevant costs has a production line that shows a $4 million loss once fixed cost is apportioned and leaves the company $4 million worse off when it closes, and CPA Australia's Management Accounting foundation exam sets 'relevant information' for 'short-term operating decisions' apart from 'long-term pricing decisions' (both checked 12 November 2026). The FinOps Framework points the other way, its first stage works on 'direct variable cost', its top stage incorporates 'fully loaded costs across all applicable technology categories' and puts them behind pricing and build-vs-buy, and the work it gives finance is to 'define allocation rules and cost structures supporting fully loaded business unit metrics'. Its definition mentions marginal cost and contribution margin, the ladder still climbs from variable cost to fully loaded and calls the top mature. For a finance reader that is not a small departure.

Ask the cloud bill what a customer costs and it answers in calls, the customer lives in billing and product data, and someone has to put one against the other. OPTIMAZE does that join: attributed supplier cost is set against a business metric, so a unit economic is built in the business's units from the start, and shared cost is spread under a declared rule, a stated basis anyone reading the number can inspect, so an allocation stays visible as one. With revenue from Stripe, Chargebee, or Metronome alongside, the same unit carries revenue and margin as well as cost. Engineering keeps cost per call, finance gets unit economics in the units the business sells.

Two questions sort any pack of metrics labelled unit economics, the first is whether the unit is one the business sells or one a supplier bills, anything in the second group is an efficiency metric, often a good one, and belongs with the engineers who can move it. For everything left, before it goes near a pricing or investment decision, the second question is whether the cost is the cost that moves with that unit, or an allocation that would be there whether the unit existed or not.

Technology Capital Performance asks whether a business's technology spend is producing a proportionate, attributable return, and a return can only be read in the units a business earns in. A board can be told what the business spends per customer, per seat, per transaction, what it spends per call tells the board about its suppliers.

If this sounds like something you and your team could use, get in contact with us.