Free Tiers as Customer Acquisition When Free Costs Money

A free tier in classic software costs a rounding error, so the design question is only about conversion. When every free user consumes inference, the free tier becomes a marketing budget that is spent automatically, by strangers, at a rate they choose.

A free tier is an acquisition channel with a bill

Treat it as a channel and compute its cost per acquired customer, the same way you would for advertising:

CAC_free = (cost per free user over their free life)
           / (conversion rate)

Assume a free user costs $0.80 a month in inference
and stays free for 3 months on average, converting
at 4%:

  cost per free user = 0.80 * 3 = $2.40
  CAC_free = 2.40 / 0.04 = $60 per paying customer

Sensitivity, because both inputs are uncertain:

  conv 2%,  cost $2.40 ->  CAC = $120
  conv 4%,  cost $2.40 ->  CAC =  $60
  conv 4%,  cost $6.00 ->  CAC = $150
  conv 8%,  cost $6.00 ->  CAC =  $75

Now the comparison that decides whether the free tier is rational: is that cheaper than your other channels, and is it below what you can afford given lifetime value? Affordability is a margin question, since acquisition is paid out of gross profit — the LTV arithmetic is in the margin-ceiling page.

A free tier can also be worth running when its CAC is unattractive, provided it produces something else you can name: developer familiarity that shortens enterprise sales, evaluation data you could not otherwise collect, a distribution effect where free users bring paying ones. Those are legitimate and they should be stated as the reason, because a justification nobody wrote down cannot be checked later.

Before designing either, separate two things that get the same name. A trial is bounded in time and is a sales instrument: it ends, cost per user is capped by the clock, and its job is to get a decision. A free tier is permanent and is a product: its cost per user has no natural end, and its job is to be useful enough to be worth keeping while leaving a reason to pay. The calculation above applies to both, but the trial has a bounded numerator by construction while the free tier does not, and the great majority of runaway free-tier costs come from a permanent tier designed as though it were a trial.

The conversion rate in the denominator is not a fixed property of your market either, and it responds to a design choice most teams make accidentally: what the free tier withholds. Withholding quantity converts users who hit the ceiling, which are the expensive ones, and produces a conversion event that feels like a toll gate. Withholding capability — collaboration, history, integrations, the better model on the tasks that warrant it — converts users who have discovered they want more, and does not require them to be heavy. The second raises r without raising cost per free user, which improves both terms of the ratio at once, and it is the rarer choice because a quantity cap is easier to implement.

The correlation that makes it worse

The calculation above uses an average free user, and the average free user does not exist. Free usage is heavy-tailed like all usage, and the tail is correlated with conversion in the wrong direction.

Split free users by consumption. Assume 10,000 of
them, a fully loaded cost of $0.012 per request, and
conversion rates that fall as consumption rises —
because the heaviest free users are the ones who have
found a way to get what they need without paying:

           share  requests  cost/user   conv   converts   cost
light       70%       20      $0.24     5.0%      350    $1,680
moderate    25%      120      $1.44     4.0%      100    $3,600
extreme      5%    1,500     $18.00     0.5%        3    $9,000

total cost                                            $14,280
total converts                                            453
CAC_free = 14,280 / 453 = $31.50

The top 5% of free users are 63% of the cost and
under 1% of the conversions.

Capping the extreme group is therefore not a minor efficiency. Remove most of that segment’s cost and the effective acquisition cost falls by roughly half while conversions are essentially unchanged. There is no equivalent move available in an advertising channel, which is what makes this the highest-leverage decision in free-tier design.

The reason for the correlation is worth stating, because it is not accidental. Someone who has engineered their workflow to fit inside a free allowance has demonstrated both high value from the product and high unwillingness to pay for it. That is precisely the profile least likely to convert and most likely to keep consuming.

The ceiling on generosity

How much can a free user be allowed to consume? Work backwards from what a converted customer is worth:

Budget per free user = r * LTV * f

  r    conversion rate
  LTV  lifetime value of a converted customer
  f    fraction of LTV you are willing to spend
       acquiring one

Assume r = 0.04, LTV = $900, f = 0.30:

  budget per free user = 0.04 * 900 * 0.30 = $10.80
                         over their entire free life

At a fully loaded $0.012 per request, that is

  900 requests total — not per month —

which is the honest basis for a free allowance, and
it is usually far less than the allowance a launch
plan proposes.

Two properties of this ceiling are worth noticing. It scales with conversion, so anything that improves conversion buys generosity. And it is a total across the free lifetime, which is an argument for allowances that do not reset forever — a monthly allowance multiplied by an unbounded number of months has no ceiling at all.

The formula also gives a clean way to argue about generosity internally, which is usually a contest between two people with different intuitions and no shared number. Growth wants a larger allowance; finance wants a smaller one; the budget per free user makes it a discussion about r and f, both of which are stated preferences rather than matters of taste. If someone wants to double the allowance, the formula says exactly what conversion rate would have to hold for that to be affordable, and that claim can be tested within a quarter.

Five design levers

When the free tier is the product

A generous free tier over a capable model is, from the outside, a free API. Somebody will build a product on top of it, and their cost of goods will be your marketing budget. This is not hypothetical — it is the predictable equilibrium whenever the free allowance is worth more than the effort of automating access to it.

The signals are behavioural rather than technical, and they are easy to look for:

• Consumption with no corresponding interface activity: requests arriving without the events a human using the product would generate.
• Machine-like regularity — even spacing, round-the-clock usage, no weekday pattern.
• Many accounts sharing an origin, a payment instrument, a device fingerprint or a signup pattern, each staying just under the cap.
• Prompt shapes that look like someone else’s application rather than like your product’s own workflow.

The response is the levers above rather than a policy document. A cap that is enforced, a rate limit, and a cheaper model on the free path make the arbitrage uneconomic, which is a more reliable defence than terms of service. And be clear internally about which problem you are solving: a negative-margin free user who is a genuine prospect is a pricing question, while one who is running a business on your allowance is not.