Free is chosen more often than it is decided. It is the default for a first app, it removes the most obvious reason someone will not try the thing, and it postpones an uncomfortable conversation about whether the work is worth money. All of that is real. What gets skipped is that free is a price, that it sets one side of the arithmetic to zero, and that the other side keeps running.
The bill arrives anyway. It is simply itemised somewhere other than the invoice: a support inbox, a server that has to stay up, an annual developer fee, and the hours that go into all three.
The slope, not the level
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:
Growth helps only when 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 does not bend that line upward, it makes it steeper downward, and the more successful the product is the faster it gets there.
Free is the decision to set \(r = 0\). That does not 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 larger number.
Support is the term that bites
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. That is half a working week, every month, arriving whether or not anything was earned, and it grows in exact proportion to how well the product is doing.
The uncomfortable part is that this cost cannot be refused without changing what the product is. Ignoring the inbox is a decision to ship something unsupported, and doing that at scale is how a free app becomes a slowly accumulating liability rather than a portfolio piece.
Being free on purpose
None of this is an argument against free. It is an argument for choosing which kind of free, of which 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 thing exists and the path to it is real rather than aspirational.
The second is free with someone else paying, through advertising or data. That sets \(r > 0\) at the cost of building a product whose customer is not its user, which is a different company than 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 is nothing to reset. No server holding user data, so there is nothing to keep up and nothing to leak. Work that happens on the device, so the marginal cost of one more install is genuinely 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. A product that must run at near-zero marginal cost cannot have a sync service, cannot have a feed, cannot have anything that phones home constantly. It has to be self-contained, which happens to also make it faster, more private and cheaper to keep alive.
So the question to answer before choosing free is not whether people will pay. It is what \(c\) is, honestly, including the hours. If it is small, free is a real option and possibly a permanent one. If it is not, then free is not a price at all, it is a deficit with a growth strategy attached, and the only fix arrives much later and costs much more than charging would have at the start.