The cost of one

Every month someone looks at the cloud bill and asks why it went up. It’s the wrong question, or at least an incomplete one, because a growing business is supposed to spend more. The useful question is whether it spends more per thing it sells.

That’s a unit cost: cloud spend divided by a unit of business value. Cost per order, per active customer, per thousand searches, per stream. Spend can rise 40% in a year while the cost of each order falls by a fifth, and only the second number tells you whether engineering is getting better.

It also changes the conversation with finance. A budget overrun driven by volume is growth that pays for itself; an overrun with rising unit cost is a problem. Unit economics is how FinOps tells the two apart.

Switch from “total spend” to “cost per order”. Same data, which story would you tell the board?

The division is the easy part. The denominator is the hard part. A good unit passes three tests: it’s something the business sells or delivers, it drives the cost (when it doubles, usage follows), and the volume data is reliable every month. For AI the denominator gets harder still: only the outcomes that meet a quality bar count.

Pick a unit that doesn’t drive cost and the ratio swings with marketing campaigns and holidays, telling a story about the denominator instead of the efficiency. Pick one that drives cost but means nothing to the business, like CPU hours, and nobody outside engineering will care about it.

Most organisations end up with one headline unit and a handful per product, plus a technical unit or two (cost per thousand requests, per gigabyte processed) for the teams that run shared platforms. The best unit is the one whose ratio stays flat when nothing changes, so that when it moves, something did.

Try each denominator. Which one gives a steady line, and which one swings with the spring campaign?

Some of the bill grows with volume and some of it doesn’t. The fixed part is the platform that has to run whether you serve one order or a million, the monitoring, the minimum capacity in three zones. The variable part is the extra compute, storage and transfer each order needs.

Unit cost is the sum of the two, and they behave very differently. The variable part per order stays roughly flat. The fixed part per order shrinks as volume grows, which is why young products look expensive per unit and get cheaper just by growing.

Knowing the split tells you where to work. A small product with a high unit cost should probably grow first. A large one whose unit cost has flattened out near its marginal cost only gets cheaper through engineering: at scale, the variable cost is the cost.

Start at 200k orders a month and double the volume three times. When does cutting the variable cost start to matter more than growing?

Put the unit cost next to revenue per unit and it becomes margin. Cloud cost to serve customers sits in cost of goods sold, so it shapes gross margin directly, and investors watch that number for any software business.

Split by customer segment, the picture usually surprises someone. A free tier that looks cheap per user can be the largest single line of cost to serve, and the biggest paying customers often earn the thinnest margins.

None of this is engineering’s call alone, which is the point. Unit economics gives product, pricing and finance a shared language: a usage cap, a new tier or an architectural change can each be priced in dollars of margin per customer.

Add the shared platform cost, then tighten the free-tier usage cap. How much margin does the cap buy back?

Once a unit cost is trusted, it makes a better unit-cost target than a budget. A budget says “spend less”, which a growing team can’t honour. A unit-cost target says “spend no more per order”, which leaves room to grow and none to get sloppy.

It also catches what totals miss. A release that makes every order 2% more expensive each week vanishes inside a bill growing 3% a week from new customers. On the unit-cost line it shows up within days, and the team that shipped it can find the commit.

Unit economics comes late in most FinOps journeys for a reason: it needs allocation, forecasting and good data all working together. When it does, cost becomes an engineering metric like latency, owned and improved by the teams themselves.

Watch the total-cost alert, then switch to the unit-cost alert. Which one catches the regression, and in which week?