Measuring Cost Per Value Delivered
TCO tells you the total cost. But total cost alone doesn't tell you if you're spending wisely. A $100,000/month AWS bill might be excellent for a company processing $50M in transactions, and catastrophic for one processing $50K. What matters is the ratio of cost to value — this is unit economics.
Unit economics means breaking down your infrastructure cost to a per-unit basis that maps to business value. The "unit" should be whatever your business actually sells or delivers:
Common Unit Economics Metrics:
Cost per request = Monthly infra cost / Monthly requests served
Cost per user = Monthly infra cost / Monthly active users
Cost per transaction = Monthly infra cost / Monthly transactions processed
Cost per GB stored = Monthly storage cost / Total GB stored
Infra cost ratio = Monthly infra cost / Monthly revenue (target: < 15–25%)
Example:
Company A:
AWS bill: $50,000/month
Monthly active users: 500,000
Cost per user: $0.10/user/month
Revenue per user: $5.00/user/month
Infra cost ratio: 2% ← Excellent
Company B:
AWS bill: $50,000/month
Monthly active users: 10,000
Cost per user: $5.00/user/month
Revenue per user: $8.00/user/month
Infra cost ratio: 62.5% ← Unsustainable
Both companies have the same AWS bill. Company A has healthy unit economics. Company B is spending most of its revenue on infrastructure and will struggle to reach profitability.
Why This Matters for Engineers:
When you propose a new service, a migration, or a platform investment, framing it in unit economics makes the business case undeniable:
- ❌ "We should migrate to Kubernetes." (Technical argument — gets ignored)
- ✅ "Migrating to Kubernetes will reduce our cost-per-transaction from $0.003 to $0.001, saving $240K/year at current volume and improving margins as we scale." (Economic argument — gets funded)
The second framing answers the question every decision-maker is silently asking: "What do I get for this money?"
Key Point: Unit economics expose a critical scaling property: does your infrastructure cost scale linearly with usage, sub-linearly (economies of scale), or super-linearly (you have an architecture problem)? If doubling your users doubles your cost, that's acceptable. If doubling your users triples your cost, you have a scaling bottleneck that will eventually kill the business. Tracking unit economics over time — not just total cost — reveals these trends before they become crises. Make cost-per-user a metric on your engineering dashboard, right next to p99 latency.