Every client who brings us a cloud bill panic has the same story. The finance team built a spreadsheet. Someone found a "15% saving" by switching a database size. Three weeks later the bill is higher and the application is slower.
Cost per unit, not cost per invoice
The fundamental mistake is tracking total spend. Total spend only goes up when you're growing — which is exactly when everyone panics. What matters is cost per meaningful unit: cost per active user, per order, per game session, per API call. That's a product metric, and it needs a product owner.
You cannot manage what finance reports at month-end. You can only manage what engineering sees in a dashboard at 9:15am.
What the dashboard actually needs
Three views, no more. A unit-cost trend line (the one metric). A drift view showing which workloads changed behaviour this week — new query paths, leaking retries, full scans. And an alerts view tied to your incident channel, so a 2× unit-cost jump pages someone the way a 2× error rate does.
Then, and only then, the levers
With unit economics visible, the levers become obvious and low-risk: right-sizing idle capacity, moving batch workloads off-peak, caches that actually hit. We've seen consistent 25–40% reductions from these — after the dashboards existed, not before.
The pattern is always the same: measure first, optimise second, and never let finance be the first person to notice.
This is the shape of a cloud platform engagement with us: unit economics first, levers second. When the metrics do not exist yet, it starts as data engineering instead.