A
Most solo founders model revenue carefully and cost casually. They know what they charge, they know roughly how many users they need, and they assume the running costs are small enough to ignore. The problem is that a one-person SaaS has two cost structures sitting on top of each other, one fixed and one per-user, and only the fixed half is visible on a pricing page. This article is about finding the invisible half: how to calculate your true marginal cost per user, why a free tier is a line item rather than a marketing channel, and which three costs scale worst as you grow.
Every SaaS has a fixed cost base and a per-user cost. Almost everyone underestimates the second one, because most vendor pricing hides it inside a monthly plan until you cross a threshold.
The distinction matters because the two behave in opposite directions. Fixed costs get cheaper per user as you grow. Per-user costs do not get cheaper at all, and some of them get worse. If you only track your total monthly spend, you cannot tell those apart. You just see a number that keeps climbing, and you assume it is the price of success.
Here is the calculation almost nobody runs. Take your infrastructure bill for last month. Take the one from three months ago. Take the user counts for both.
Then:
That number is what one additional user costs you, and it is the only cost figure that matters when you are deciding whether to open a free tier, whether your price is high enough, or whether that enterprise prospect asking for unlimited storage is worth having.
A worked example.
Say three months ago you had 40 users and a 90 a month infrastructure bill. Today you have 180 users and a 265 bill.
At a 29 a month price point, that looks wonderful. Ninety six percent gross margin. This is the number founders quote in public. But run it again including the things that are not on the infrastructure invoice, and it changes shape. More on that in a moment.
Two cautions on this calculation. It only works if nothing structural changed between the two dates, so exclude the month you migrated hosts or added a major vendor. And it will understate reality if your costs are stepped rather than smooth, which most are. Which brings us to the real problem.
Cloud pricing pages present costs as continuous. Reality is a staircase.
You are on a database plan that covers you until a connection limit, and then the next tier is not slightly more expensive, it is double. Your email provider is free to 3,000 sends a month and then it is not. Your error tracking tool covers a certain event volume and then it starts sampling, or charging.
This has a specific consequence that catches people out: your costs will look flat for months and then jump, and the jump will not coincide with a proportional jump in revenue.
A founder watching a flat cost line for four months concludes their margins are structurally excellent. They are not. They are sitting between two steps.
What to do about it: for each vendor in your stack, write down the next threshold and the price on the other side of it. Not the current bill, the next step. That single page tells you what your cost base looks like at two or three times your current size, which is the only version of it worth planning against.
Now the part in the title. A free tier is a marketing channel with a variable cost, and it stops being a marketing channel at a specific, calculable point.
Set it up like this. Your free tier costs you your marginal cost per user, multiplied by the number of free users. It earns you revenue only through conversion.
So:
Cancel the free user count from both sides and you get something much clearer:
The free tier is worth running when the conversion rate multiplied by your price exceeds what a free user costs you. The number of free users does not appear at all, which is the counterintuitive part. Scale does not fix a broken free tier. It multiplies it.
A worked example. Say a free user costs you 0.40 a month in storage and compute, you convert 2 percent of free users to paid, and your price is 29.
That works, but only barely. You are netting 0.18 per free user per month, which means a thousand free users generate 180 a month of value. Real, but not the growth engine it feels like.
Now change one variable. Make free users heavier, say 1.10 a month because you gave them generous storage:
You are now losing 0.52 per free user per month, and every marketing win makes it worse. A successful launch that brings 2,000 signups costs you over 1,000 a month and you will experience it as "our infrastructure costs exploded after launch."
The lever is rarely the conversion rate. Moving 2 percent to 4 percent is months of product work. Moving free-user cost from 1.10 to 0.40 is usually a storage cap, a retention policy on old data, or turning off an expensive feature below the paid line. That is an afternoon.
Not all per-user costs behave the same way. Three are consistently worse than founders expect.
Support time. This is the big one, and it does not appear on any invoice. Support volume scales roughly with user count, but your capacity to answer it does not scale at all, because you are one person. At some user count your support load consumes the hours you were using to build, and growth quietly stops. Everyone models storage. Almost nobody models this.
Egress and bandwidth. Storage is cheap and getting cheaper. Moving data out is neither. If your product serves files, images, exports or video, egress is the line item most likely to surprise you, because it scales with usage rather than with user count. One power user can cost more than a hundred ordinary ones.
Per-seat vendor pricing inside your own stack. If you use a tool that charges per seat or per tracked user and you pass your own users through it, you have accidentally coupled your cost base to your growth at someone else's margin. Analytics tools, customer messaging tools and auth providers all do this. Check whether any vendor's pricing metric is the same as your growth metric, because if it is, you are growing their revenue at your expense.
Your time is the largest cost in the business and it is almost never in the model.
The reason is understandable. It does not leave your bank account, so it does not feel like a cost. But if you are spending fifteen hours a week on a product that nets 800 a month, you are earning about 12 an hour, and you should at least know that rather than discover it two years in.
Put an hourly figure on your time and add it to the cost side.
Not because you will pay yourself, but because it changes decisions:
This is the calculation that turns "I am busy and it is growing" into "I know which parts of this are worth my time."
Run these five numbers, once, and keep them somewhere you will see them:
With those five, most of the hard questions answer themselves. Whether to open a free tier. Whether 29 is enough. Whether that feature request is worth building. Whether the business is actually working, or just busy.
The uncomfortable version: a one-person SaaS with excellent gross margins and a founder working twenty unpaid hours a week is not a high-margin business. It is a job with an infrastructure bill, and the only difference between the two is whether you have run the numbers.
Run them.
The Two Cost Structures
Every SaaS has a fixed cost base and a per-user cost. Almost everyone underestimates the second one, because most vendor pricing hides it inside a monthly plan until you cross a threshold.
- Fixed costs are the ones you pay whether you have ten users or ten thousand. Your domain, your base hosting plan, the CI runner, the design tool, the accountant. These are easy to see because they arrive as identical invoices every month, and they are the ones founders can usually recite from memory.
- Per-user costs are the ones that move with usage. Database rows, storage, bandwidth, email sends, background job minutes, the per-seat tier on a vendor tool, the API calls your product makes on behalf of a user. These are invisible until they are not.
The distinction matters because the two behave in opposite directions. Fixed costs get cheaper per user as you grow. Per-user costs do not get cheaper at all, and some of them get worse. If you only track your total monthly spend, you cannot tell those apart. You just see a number that keeps climbing, and you assume it is the price of success.
Work Out Your Marginal Cost Per User
Here is the calculation almost nobody runs. Take your infrastructure bill for last month. Take the one from three months ago. Take the user counts for both.
Then:
Code:
(this month's bill - three months ago's bill)
divided by
(this month's users - three months ago's users)
= your marginal cost per userThat number is what one additional user costs you, and it is the only cost figure that matters when you are deciding whether to open a free tier, whether your price is high enough, or whether that enterprise prospect asking for unlimited storage is worth having.
A worked example.
Say three months ago you had 40 users and a 90 a month infrastructure bill. Today you have 180 users and a 265 bill.
Code:
(265 - 90) / (180 - 40) = 1.25 per user per monthAt a 29 a month price point, that looks wonderful. Ninety six percent gross margin. This is the number founders quote in public. But run it again including the things that are not on the infrastructure invoice, and it changes shape. More on that in a moment.
Two cautions on this calculation. It only works if nothing structural changed between the two dates, so exclude the month you migrated hosts or added a major vendor. And it will understate reality if your costs are stepped rather than smooth, which most are. Which brings us to the real problem.
Costs Are Stepped, Not Smooth
Cloud pricing pages present costs as continuous. Reality is a staircase.
You are on a database plan that covers you until a connection limit, and then the next tier is not slightly more expensive, it is double. Your email provider is free to 3,000 sends a month and then it is not. Your error tracking tool covers a certain event volume and then it starts sampling, or charging.
This has a specific consequence that catches people out: your costs will look flat for months and then jump, and the jump will not coincide with a proportional jump in revenue.
A founder watching a flat cost line for four months concludes their margins are structurally excellent. They are not. They are sitting between two steps.
What to do about it: for each vendor in your stack, write down the next threshold and the price on the other side of it. Not the current bill, the next step. That single page tells you what your cost base looks like at two or three times your current size, which is the only version of it worth planning against.
The Free Tier Crossover
Now the part in the title. A free tier is a marketing channel with a variable cost, and it stops being a marketing channel at a specific, calculable point.
Set it up like this. Your free tier costs you your marginal cost per user, multiplied by the number of free users. It earns you revenue only through conversion.
So:
Code:
free tier is worth it while:
(free users x conversion rate x price) > (free users x marginal cost per free user)Cancel the free user count from both sides and you get something much clearer:
Code:
conversion rate x price > marginal cost per free userThe free tier is worth running when the conversion rate multiplied by your price exceeds what a free user costs you. The number of free users does not appear at all, which is the counterintuitive part. Scale does not fix a broken free tier. It multiplies it.
A worked example. Say a free user costs you 0.40 a month in storage and compute, you convert 2 percent of free users to paid, and your price is 29.
Code:
0.02 x 29 = 0.58 earned per free user per month
0.40 spent per free user per monthThat works, but only barely. You are netting 0.18 per free user per month, which means a thousand free users generate 180 a month of value. Real, but not the growth engine it feels like.
Now change one variable. Make free users heavier, say 1.10 a month because you gave them generous storage:
Code:
0.02 x 29 = 0.58 earned
1.10 spentYou are now losing 0.52 per free user per month, and every marketing win makes it worse. A successful launch that brings 2,000 signups costs you over 1,000 a month and you will experience it as "our infrastructure costs exploded after launch."
The lever is rarely the conversion rate. Moving 2 percent to 4 percent is months of product work. Moving free-user cost from 1.10 to 0.40 is usually a storage cap, a retention policy on old data, or turning off an expensive feature below the paid line. That is an afternoon.
The Three Costs That Scale Worst
Not all per-user costs behave the same way. Three are consistently worse than founders expect.
Support time. This is the big one, and it does not appear on any invoice. Support volume scales roughly with user count, but your capacity to answer it does not scale at all, because you are one person. At some user count your support load consumes the hours you were using to build, and growth quietly stops. Everyone models storage. Almost nobody models this.
Egress and bandwidth. Storage is cheap and getting cheaper. Moving data out is neither. If your product serves files, images, exports or video, egress is the line item most likely to surprise you, because it scales with usage rather than with user count. One power user can cost more than a hundred ordinary ones.
Per-seat vendor pricing inside your own stack. If you use a tool that charges per seat or per tracked user and you pass your own users through it, you have accidentally coupled your cost base to your growth at someone else's margin. Analytics tools, customer messaging tools and auth providers all do this. Check whether any vendor's pricing metric is the same as your growth metric, because if it is, you are growing their revenue at your expense.
The Line Item You Are Not Counting
Your time is the largest cost in the business and it is almost never in the model.
The reason is understandable. It does not leave your bank account, so it does not feel like a cost. But if you are spending fifteen hours a week on a product that nets 800 a month, you are earning about 12 an hour, and you should at least know that rather than discover it two years in.
Put an hourly figure on your time and add it to the cost side.
Not because you will pay yourself, but because it changes decisions:
- A feature that takes 30 hours and prevents 2 churned users a month at 29 each is not obviously worth building
- A support burden of 6 hours a week is a real cost, and automating it has a calculable payback
- A customer who takes an hour a month of hand-holding on a 29 plan is unprofitable, and you cannot see that without pricing your hours
This is the calculation that turns "I am busy and it is growing" into "I know which parts of this are worth my time."
Putting It Together
Run these five numbers, once, and keep them somewhere you will see them:
- Fixed monthly cost. Everything you pay regardless of users.
- Marginal cost per paid user. Use the three month delta calculation above.
- Marginal cost per free user. Usually lower, but check, because free users are sometimes heavier than paid ones.
- The next threshold on every vendor. What breaks first as you grow, and what it costs on the other side.
- Your hourly rate, applied to real hours. Including support.
With those five, most of the hard questions answer themselves. Whether to open a free tier. Whether 29 is enough. Whether that feature request is worth building. Whether the business is actually working, or just busy.
The uncomfortable version: a one-person SaaS with excellent gross margins and a founder working twenty unpaid hours a week is not a high-margin business. It is a job with an infrastructure bill, and the only difference between the two is whether you have run the numbers.
Run them.