A B2B SaaS adds a free tier to feed its sales pipeline. Within a quarter free accounts outnumber paid ones about 20 to 1, infrastructure spend is up 35% and revenue is flat. The pricing page took a day to change. What did that decision commit the architecture to, and what should have shipped alongside it?

What was gained

A free tier is a distribution mechanism. It buys reach and a signal about which accounts are worth a salesperson's time, and it is often the cheapest acquisition channel a B2B product has. That part worked: 20 free accounts per paid one is a healthy funnel shape.

What is paid

A pricing decision made in a day created a permanent, unbounded category of users who have no commercial incentive to be efficient and no identity check behind them. Three bills arrive.

Cost per free account becomes a hard constraint and nobody set it. If a free account costs £1.40 a month and a paid one yields £90, then 20 to 1 means £28 of free cost against £90 of revenue per paid account: 31% of gross revenue going to non-customers. That is survivable. At £4 a month per free account it is 89% and the business is insolvent at scale. The number that matters is cost per free account per month, and it must be a budget enforced by a mechanism, not an outcome measured afterwards.

Abuse becomes an engineering problem. Unverified sign-ups are a resource for anyone who wants compute, storage, email reputation or an outbound IP. A free tier without identity friction will be found, usually within weeks.

Noisy neighbours now have no revenue attached. A free account running an expensive query shares the same database, queue and worker pool as a paying one.

What should have shipped with the tier

• A quota enforced at the cheapest layer that can see it. API calls, storage, rows, compute-seconds: whichever dimension drives cost. Enforce at the gateway where the check is microseconds, not inside the application where the work is already done.
• A priority class, so free work is shed first. Separate queues or a weighted scheduler, so the degradation order is a design decision rather than whichever request happens to arrive.
• A per-account cost figure in the same place as the usage figure, so the unit economics are visible monthly rather than discovered in a quarterly review.
• Dormancy and deletion. Free accounts accumulate forever otherwise, and storage is the line that never goes down. A 90-day inactivity archive is usually the single biggest saving.
• Enough identity friction to make abuse uneconomic: a verified work email or a card on file with no charge. Each point of friction cuts the funnel, which is the real trade-off, and it belongs to the product owner rather than to engineering.

When this is the wrong answer

When the free tier is deliberately a loss leader with a known burn and a funded runway, and the company has decided that growth now is worth the cost. The failure here is not the free tier, it is that nobody priced it: the architecture was committed by a pricing page, and the mechanisms that bound the cost were never on anyone's backlog. Build the quota layer before the tier, or accept that you will build it under cost pressure six months later while explaining a 35% spend rise.