Most people drift into free rather than choosing it. It's the default for a first app, it removes the most obvious reason not to try something, and it puts off an awkward conversation about whether the work is worth paying for. All of that is true. What gets missed is that free is still a price. It sets one side of the sum to zero, and the other side keeps running.
The bill still arrives. It just turns up somewhere other than an invoice: a support inbox, a server that has to stay up, a yearly developer fee, and the hours that go into all three.
Growth only helps if the maths works
Take a product with \(u\) active users, some revenue \(r\) per user per month, some marginal cost \(c\) per user per month, and fixed costs \(f\) that exist whether anyone shows up or not. Monthly profit is:
Growing only helps if the bracket is positive.
The bracket decides everything, and it decides it before the first user arrives. If \(r > c\), scale is the answer to almost any problem: every new user pays for themselves and contributes toward \(f\), and the whole thing eventually crosses into profit on its own. If \(r < c\), scale is the problem. Growth doesn't bend that line upward. It makes it fall faster, and the more successful the product is, the quicker you get there.
Choosing free means setting \(r = 0\). Zero revenue doesn't make the bracket zero. It makes it \(-c\). Whatever \(c\) is, the product now loses that much per user per month, forever, and the reward for good marketing is a bigger number.
Support is the cost that grows
Servers are the cost people plan for and usually the smaller one. At a fraction of a cent per user per month, fifty thousand people cost less to host than a modest dinner. The term that actually scales is the human one.
Suppose one user in five hundred writes in during a given month, which is not pessimistic for a consumer app, and each message takes ten minutes to read, reproduce and answer properly. Fifty thousand active users is then a hundred messages a month, or about seventeen hours. Seventeen hours is half a working week, arriving every month whether or not anything was earned, and it grows in exact proportion to how well the product is doing.
The awkward part is that you can't avoid this cost without changing what the product is. Ignoring the inbox means shipping something unsupported, and doing that at scale is how a free app turns into a growing liability instead of something worth owning.
Being free on purpose
None of this is an argument against free. It's an argument for deciding which kind of free you mean, and there are only three honest versions.
The first is free as a funnel, where \(r\) is zero now and deliberately not later. That works, but only if the paid product actually exists and the route to it is real rather than wishful.
The second is free with someone else paying, through advertising or data. That gets \(r > 0\), but it means building a product whose customer isn't its user, and that's a different company from the one we want to run.
The third is the one we keep choosing: free with \(c\) driven as close to zero as the product allows. No accounts, so there's nothing to reset. No server holding user data, so there's nothing to keep running and nothing to leak. The work happens on the device, so one more install really does cost almost nothing. Then \(-c\) is small enough that scale is affordable, and a free product can sit in the portfolio for years without asking for anything.
That constraint shapes the software more than any design decision does. A product that has to run at almost no cost per user can't have a sync service, can't have a feed, can't have anything that phones home constantly. It has to be self-contained, which also makes it faster, more private and cheaper to keep alive.
So the question to answer before choosing free isn't whether people will pay. It's what \(c\) really is, hours included. If it's small, free is a real option and maybe a permanent one. If it isn't, what you have is a loss that grows as you grow, and the fix arrives years later at a price you could have charged from the start.