What one user costs you

One number that settles a lot of arguments

Take last month’s infrastructure bill and divide it by the number of monthly active users. That is your cost per user, and it is the number that tells you whether a free tier is generous or reckless, whether a feature is affordable, and whether your architecture has to change.

Most small projects have never computed it, and are surprised in both directions. A content site with a CDN and a small database can run at a fraction of a cent per user per month. A product where every visit triggers model calls and image processing can be tens of cents: a hundred times more, for something that looks similar from the outside.

Compute it properly, once

Split the bill into fixed and variable:

• Fixed: the machines, the database, the monitoring, the domain. These do not move with usage. At small scale this is nearly all of your bill, which is why cost per user falls sharply as you grow: the first hundred users are extremely expensive each.
• Variable: bandwidth, model tokens, email, storage, per-request charges. These scale with usage and eventually dominate.

Then compute the variable cost of one action, not one user, because that is where the design decisions are. From the earlier lessons: a model call at $0.0008, an email at a fraction of a cent, a megabyte of egress at about a hundredth of a cent (8 to 12 US cents per gigabyte) on a metered provider and free behind some CDNs, a stored photo at roughly two cents per gigabyte-month plus its derivatives.

Now multiply by how often an average user does each thing per month. The answer is usually dominated by one line, and that line is where all the useful work is.

The three shapes of a per-user cost problem

1. A heavy free tier. Anonymous or free users doing something expensive: generation, transcoding, search over a large index. The fix is a quota by identity tier, exactly as this project’s own ladder does: more capability as somebody proves they are a person, with the expensive operations reserved for accounts.

2. Storage that only grows. Every upload stays forever, along with three derivative sizes nobody looks at. Storage is cheap per gigabyte and infinite over time. The fix is a lifecycle policy and a retention decision per class of data, which the deletion lesson already required you to have for other reasons.

3. A per-request external cost. Any external API in the request path makes your marginal cost non-zero, and abuse becomes directly expensive rather than merely annoying. Cache, quota, and put the expensive call behind an account.

When the architecture has to change

A useful test: multiply your current cost per user by ten times the users. If the answer is fine, your architecture is fine and you should not redesign anything. If the answer is alarming, find the one line item responsible (it will be one) and fix that, not the architecture.

Almost every “we need to rearchitect for scale” conversation in a small product is actually one uncached endpoint, one missing index, one image not resized, or one model call that could be a cheaper model. Rewrites are the most expensive way to reduce a bill.

Free forever

Some projects, this one included, commit to being free permanently. That is a real commitment with a real arithmetic consequence: cost per user must stay low enough that the funding source, whatever it is, can carry the whole user base. It is achievable, and it constrains design in specific ways:

• Reading must be cheap. Static, cached, served from an edge.
• Expensive operations need a per-person daily budget, enforced in code before the call, not a hope that nobody abuses it.
• Storage growth must have a policy, or it becomes a permanent rising cost with no ceiling.
• Anything with a per-token or per-request price needs a hard monthly cap at the provider, so a bad week cannot become an unpayable invoice.

Saying “free” and meaning it is an engineering constraint, not just a promise on a page.

Track it monthly, in one row

A table with five columns (month, total bill, active users, cost per user, and the largest line item) takes five minutes to fill in and makes the trend visible. A cost per user that is falling means you are growing into your fixed costs. One that is rising means a variable line has started to dominate, and you have found it early enough to do something cheap about it.