Every quarter someone asks why the cloud bill went up. "Because we grew" is usually true and never satisfying. Unit economics answers the better question: did each customer, order or request get cheaper or more expensive to serve? If the bill grew 30 percent while active customers grew 45 percent, cost per customer went down, and engineering did well. If the bill grew 30 percent and customers grew 5 percent, something needs attention.

This guide is how we built unit cost metrics for our SaaS product with a small team, what we got wrong first, and how the numbers changed decisions.

Choose units people already care about

A good unit is something the business already tracks, that drives cost, and that changes over time. Candidates:

Unit Good for Watch out for
Active customer (account) per month SaaS with account-based pricing Very different customer sizes
Paying seat or user Seat-based pricing Free users still cost money
Order, transaction, message Usage-driven products Seasonality
1,000 API requests Platform and API products Request cost varies by endpoint
GB stored or processed Data products Mixing hot and cold data

We use two: cost per active paying account per month (for pricing and margins) and cost per 1,000 API requests (for engineering efficiency). One for the business, one for engineers.

Decide what cost goes in the numerator

Start from allocated cloud cost (see our post on Kubernetes cost allocation) and decide explicitly:

  • Production only, or everything? We include production plus shared infrastructure, and report non-production separately. Including staging hides production efficiency changes.
  • Amortised commitments. Use effective cost with Savings Plans and reservations amortised, otherwise a commitment purchase month looks terrible.
  • Third-party services. Observability, CDN, email and LLM APIs are often as large as compute. Include them if they scale with the unit.
  • People. Leave out. This is cost to serve, not total cost of engineering.

Allocate shared costs with simple keys

Most cost is shared: one database cluster, one Kubernetes cluster, one CDN. Allocation keys spread it:

  • Direct: resources tagged to a product or tenant go straight there.
  • Proportional to usage: shared databases by query time or storage per tenant, Kubernetes by allocated CPU and memory, CDN by bytes per tenant.
  • Even split: for small shared items where measurement costs more than it helps.

Do not chase precision. A model that is 90 percent right and updated monthly beats a perfect model that nobody maintains.

Get the denominator from the source of truth

Unit counts must come from the same system the business uses: the billing system for paying accounts, the API gateway for requests. We pull them daily into the same warehouse as billing data (FOCUS exports in our case), so the join is one query:

WITH cost AS (
  SELECT DATE_TRUNC(ChargePeriodStart, MONTH) AS month, SUM(EffectiveCost) AS cost
  FROM finops.focus_all
  WHERE Tags['environment'] IN ('production', 'shared')
  GROUP BY 1
),
units AS (
  SELECT month, COUNT(DISTINCT account_id) AS active_paying_accounts
  FROM billing.account_activity
  WHERE is_paying AND had_activity
  GROUP BY 1
)
SELECT month, cost, active_paying_accounts,
       ROUND(cost / active_paying_accounts, 2) AS cost_per_account
FROM cost JOIN units USING (month)
ORDER BY month;

Segment before you conclude

An average cost per account hides the interesting part. Splitting by plan showed our largest 3 percent of accounts generated 41 percent of cost, mostly from search indexing and file storage. That one breakdown led to two decisions: a storage limit on the mid tier, and a re-architecture of search indexing for large tenants.

Per-tenant cost needs per-tenant metering: request counts, storage, and heavy job runtimes tagged with tenant ids. We added tenant ids to job metrics and storage paths; that work paid for itself within a quarter.

Use it in decisions

Unit costs are useful when they appear where decisions are made:

  • Pricing: gross margin per plan, using cost per account by plan.
  • Architecture reviews: proposals include estimated change in cost per 1,000 requests.
  • Engineering goals: a quarterly target such as "reduce cost per 1,000 requests by 10 percent" is clearer than "reduce the bill", which growth can make impossible.
  • Anomaly detection: unit cost spikes catch problems that total cost hides during growth.

Communicating the numbers

Unit costs travel better than totals. Our monthly engineering update shows three lines: cost per active paying account, cost per 1,000 API requests, and their three-month trend, each with one sentence explaining the biggest change. Finance uses the same numbers in margin reports, so engineering and finance discuss one set of figures. When a unit cost rises, the owning team writes a short note: what changed, whether it was expected (a new feature with real value) or not (an inefficiency to fix), and what happens next. Over a year, that habit did more for cost awareness than any dashboard.

Watch for misleading trends

Unit costs can improve for bad reasons, such as a big customer joining whose usage is light at first, or get worse for good ones, such as a new feature that customers love. Pair each unit metric with a short note on mix changes, and look at segments before celebrating or panicking.

Common mistakes

Mistake Why it hurts Do this instead
Units nobody else tracks Numbers ignored Use business metrics as denominators
Including non-production Masks production changes Report non-production separately
Using billed cost with commitments Spiky, misleading months Use amortised effective cost
Only averages Hides expensive segments Segment by plan, tenant size, feature
Perfect allocation models Never finished, never updated Simple keys, monthly refresh

Key takeaways

  • Unit costs show efficiency independent of growth.
  • Pick one business unit and one engineering unit.
  • Allocate shared costs with simple, documented keys.
  • Segment by customer size and plan to find what drives cost.
  • Put unit costs in pricing, architecture and goal-setting discussions.

References