{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"the-cost-per-user","title":"What one user costs you","url":"https://addaly.com/learn/cloud-and-shipping/the-cost-per-user","position":69,"of":74,"minutes":9,"answer":"Divide the bill by active users, split it into fixed and variable, and price the one action that dominates the variable half; then test whether ten times the users would still be affordable.","keyIdea":"Divide the bill by active users, split it into fixed and variable, and price the one action that dominates the variable half; then test whether ten times the users would still be affordable, because the answer is nearly always one line item rather than the architecture."},"body":{"format":"markdown","text":"## One number that settles a lot of arguments\n\nTake 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.\n\nMost 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.\n\n## Compute it properly, once\n\nSplit the bill into fixed and variable:\n\n- **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.\n- **Variable:** bandwidth, model tokens, email, storage, per-request charges. These scale with usage and eventually dominate.\n\nThen 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.\n\nNow 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.\n\n> Figure: Cost per user falls into the fixed costs, then flattens. Line chart of US dollars per user per month against monthly active users: Total bill divided by active users (100, 0.62) (500, 0.14) (1000, 0.08) (2000, 0.05) (5000, 0.032) (10000, 0.026). A site with 60 dollars a month of fixed cost and two cents of variable cost per user. The first hundred users cost sixty-two cents each; at ten thousand the fixed half has vanished and the two-cent line is all that is left. That variable line is where the design decisions are.\n\n## The three shapes of a per-user cost problem\n\n**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.\n\n**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.\n\n**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.\n\n## When the architecture has to change\n\nA 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.\n\nAlmost 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.\n\n## Free forever\n\nSome 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:\n\n- Reading must be cheap. Static, cached, served from an edge.\n- Expensive operations need a per-person daily budget, enforced in code before the call, not a hope that nobody abuses it.\n- Storage growth must have a policy, or it becomes a permanent rising cost with no ceiling.\n- 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.\n\nSaying \"free\" and meaning it is an engineering constraint, not just a promise on a page.\n\n## Track it monthly, in one row\n\nA 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."},"check":{"question":"A project's monthly bill is 90% fixed. Users double and the bill rises by 4%. What does this indicate about the next growth decision?","options":[{"text":"The architecture is nearly free to scale and no cost work is needed at any size","correct":false,"tempting":"Extrapolates a small step indefinitely; fixed costs eventually saturate and the variable share grows, so the conclusion holds only near current usage."},{"text":"Growth is currently cheap because fixed costs dominate, so the useful question is which variable line grows fastest as that changes","correct":true},{"text":"The bill is mostly waste, since costs did not track usage","correct":false,"tempting":"Fixed costs are not waste; a database and a machine must exist before the first user and are the reason early users appear expensive."},{"text":"Cost per user is meaningless while fixed costs dominate","correct":false,"tempting":"It is dominated by fixed costs, which is informative in itself: it tells you exactly where you are on the curve rather than making the metric useless."}]},"prev":{"slug":"upgrades-and-end-of-life","title":"The upgrade you keep postponing","url":"https://addaly.com/learn/cloud-and-shipping/upgrades-and-end-of-life"},"next":{"slug":"moving-house","title":"Moving to another provider without losing a URL","url":"https://addaly.com/learn/cloud-and-shipping/moving-house"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'What one user costs you', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/the-cost-per-user (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"What one user costs you","courseTitle":"Shipping It","module":{"index":8,"slug":"running-it-for-years","title":"Running it for years"},"answer":null,"keyIdea":"Divide the bill by active users, split it into fixed and variable, and price the one action that dominates the variable half; then test whether ten times the users would still be affordable, because the answer is nearly always one line item rather than the architecture.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure","figure":{"type":"line","title":"Cost per user falls into the fixed costs, then flattens","series":[{"label":"Total bill divided by active users","points":[[100,0.62],[500,0.14],[1000,0.08],[2000,0.05],[5000,0.032],[10000,0.026]]}],"xLabel":"monthly active users","yLabel":"US dollars per user per month","caption":"A site with 60 dollars a month of fixed cost and two cents of variable cost per user. The first hundred users cost sixty-two cents each; at ten thousand the fixed half has vanished and the two-cent line is all that is left. That variable line is where the design decisions are."},"alt":"Figure: Cost per user falls into the fixed costs, then flattens. Line chart of US dollars per user per month against monthly active users: Total bill divided by active users (100, 0.62) (500, 0.14) (1000, 0.08) (2000, 0.05) (5000, 0.032) (10000, 0.026). A site with 60 dollars a month of fixed cost and two cents of variable cost per user. The first hundred users cost sixty-two cents each; at ten thousand the fixed half has vanished and the two-cent line is all that is left. That variable line is where the design decisions are."}},"blocks":[{"t":"h2","id":"one-number-that-settles-a-lot-of-arguments","runs":[{"text":"One number that settles a lot of arguments"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"compute-it-properly-once","runs":[{"text":"Compute it properly, once"}]},{"t":"p","runs":[{"text":"Split the bill into fixed and variable:"}]},{"t":"ul","items":[[{"text":"Fixed:","b":true},{"text":" 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."}],[{"text":"Variable:","b":true},{"text":" bandwidth, model tokens, email, storage, per-request charges. These scale with usage and eventually dominate."}]]},{"t":"p","runs":[{"text":"Then compute the variable cost of one "},{"text":"action","i":true},{"text":", 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-three-shapes-of-a-per-user-cost-problem","runs":[{"text":"The three shapes of a per-user cost problem"}]},{"t":"p","runs":[{"text":"1. A heavy free tier.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"2. Storage that only grows.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"3. A per-request external cost.","b":true},{"text":" 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."}]},{"t":"h2","id":"when-the-architecture-has-to-change","runs":[{"text":"When the architecture has to change"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"free-forever","runs":[{"text":"Free forever"}]},{"t":"p","runs":[{"text":"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:"}]},{"t":"ul","items":[[{"text":"Reading must be cheap. Static, cached, served from an edge."}],[{"text":"Expensive operations need a per-person daily budget, enforced in code before the call, not a hope that nobody abuses it."}],[{"text":"Storage growth must have a policy, or it becomes a permanent rising cost with no ceiling."}],[{"text":"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."}]]},{"t":"p","runs":[{"text":"Saying “free” and meaning it is an engineering constraint, not just a promise on a page."}]},{"t":"h2","id":"track-it-monthly-in-one-row","runs":[{"text":"Track it monthly, in one row"}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A project’s monthly bill is 90% fixed. Users double and the bill rises by 4%. What does this indicate about the next growth decision?"}],"options":[{"text":[{"text":"The architecture is nearly free to scale and no cost work is needed at any size"}],"correct":false,"tempting":[{"text":"Extrapolates a small step indefinitely; fixed costs eventually saturate and the variable share grows, so the conclusion holds only near current usage."}]},{"text":[{"text":"Growth is currently cheap because fixed costs dominate, so the useful question is which variable line grows fastest as that changes"}],"correct":true,"tempting":null},{"text":[{"text":"The bill is mostly waste, since costs did not track usage"}],"correct":false,"tempting":[{"text":"Fixed costs are not waste; a database and a machine must exist before the first user and are the reason early users appear expensive."}]},{"text":[{"text":"Cost per user is meaningless while fixed costs dominate"}],"correct":false,"tempting":[{"text":"It is dominated by fixed costs, which is informative in itself: it tells you exactly where you are on the curve rather than making the metric useless."}]}],"order":[0,2,1,3],"why":null},"prev":{"slug":"upgrades-and-end-of-life","title":"The upgrade you keep postponing","minutes":9},"next":{"slug":"moving-house","title":"Moving to another provider without losing a URL","minutes":9}}}