How did you size your free tier?

adolphchen's version is the one I would build on. if the free tier has to let someone finish one real task, then the boundary is an outcome rather than a quantity, and that quietly dissolves your question instead of answering it. there is no number to size, because the limit is set by their result rather than by your estimate of what feels fair.

we do it that way on affiliate software, free until the first affiliate actually signs up, and the useful part is that there is no figure sitting there waiting to be revisited.

two conditions though, which is why it is not universal. the outcome has to be unambiguous and observable from your side, and serving a pre-outcome user has to be cheap. if every free user is costing you inference money, outcome gating just moves the problem somewhere else.

on your last line, never really revisiting it is the part I would worry about most. a number picked by gut feel becomes load-bearing, and every pricing decision after it inherits the number without anyone deciding that it should.

I’m new to this and haven’t designed a pricing model before, but as a user I’d want the free tier to let me finish one real task.

If the limit appears halfway through, I probably won’t pay because I still haven’t seen the result. If I can complete something useful first, paying makes more sense. Do you know which first result makes your users most likely to come back?

What stood out to me is the shift from treating feedback as something to accumulate to treating it as something that should reduce uncertainty.

The value isn't really in having more customer voices. It's in reaching a point where the next decision becomes clearer because of them.

Look at median usage of active free users, cap slightly below. Above that you're hosting freeloaders. Below it nobody gets enough value to stick around.

One thing that doesn't show up in "cost per unit" thinking if your product is an automation tool rather than a one-shot generator: the free tier also has to prove the automation actually runs on its own, not just that the output is good once. A single free generation only proves quality. It doesn't prove the recurring/scheduled part of the pitch, which for a lot of AI tools is the actual value prop over doing it manually once.

Mine is 3/month specifically so a free user sees the full cycle (research the next thing to do, generate it, publish it) happen more than once without me touching it, not just a single impressive output. The AI cost per unit is trivial for me, so cost wasn't the binding constraint at all, proof of "this genuinely runs itself" was.

I sized mine by working backwards from unit cost instead of guessing a number. Once I knew exactly what one "unit" of my product costs me to deliver, the free tier became a marketing budget line: 10 units/month costs me about a dollar per active free user, which is cheaper than any ad click I can buy for the same attention. Two things I'd do again: make it monthly-recurring rather than one-time (a recurring reason to come back beats a one-shot trial), and never gate the core output — free users who see the full value of one complete result convert; free users who see a teaser churn. The mistake I see most: sizing free by "what feels generous" instead of "what does this cost me vs. what's a signup worth."

I think this is one of the hardest product decisions because the free tier needs to be useful enough for someone to experience the value, but limited enough that there is still a clear reason to upgrade. If it is too restricted, users leave before understanding the product. If it is too generous, they may never convert. Did you choose the limits based on usage, features, number of projects, or the cost of supporting each free user?

We're in the early stages of getting organic users, so we just decided an arbitrary "seems like a lot" threshold per user, above which it's likely to be malicious. We can afford to lose money at this stage, and this way we don't discourage any early adopters.

I went with outcome-based gating like Mihir describes, mostly by accident. Free is unlimited entries but capped at 2 projects, and the third project is what triggers the paywall. My logic was that wanting a third project means the habit already formed, so the ask lands at the moment of proven value instead of interrupting week one. No idea if it works yet, app is still in review, so consider this a hypothesis not a lesson.

+1 to the outcome-based framing over a quantity. The version I've landed on: the free tier should let someone reach the one moment that proves the app works for them, and the paywall sits just past it — not at an arbitrary count. It also fits how I think about design generally: a limit tied to an outcome ("you finished your first real thing") is one the user understands instantly, whereas "you've used 3 of 5" is a number they have to reason about and resent. The caveat in the other comment is right, though — whatever you pick becomes load-bearing fast, so choose the boundary you can still defend a year from now, because every later pricing decision quietly inherits it.

For me it comes down to a question you didn't list: how much does a free user actually cost you? My product hits an AI model on every action, so free users cost me real money whether they convert or not. If your marginal cost is basically zero, you can afford to be generous. If it's not, the free tier is a real expense and cost kind of has to be your starting point.

Other thing I learned the hard way: don't cap people before they've felt the product work at least once. If someone hits the limit before the "oh nice" moment, they just leave thinking it's useless. Let them win once, then cap.

And I wouldn't overthink the exact number upfront. Pick one, ship it, then look at what share of free users actually hit it. If nobody does, it's too loose and you're paying for freeloaders. If people hit it in the first few minutes, too tight. You want the number a real engaged user reaches after a few days, not minutes.

The bit that stood out in your post was "never revisited it". That's the one I'd fix. Throw a reminder in your calendar to look at it monthly, because that first guess quietly becomes your whole pricing.

Btw what's your cost per free user like, near zero or actually meaningful? Changes the answer a lot.

One dimension missing from the options in your post: what a free unit costs you when the cost is not infrastructure but shared reputation.

I am the founder/operator of Lisar Connect, so for me the marginal cost of a free user is not compute, it is that traffic leaves through infrastructure that paying customers also use. Unattended free usage on that kind of product is not just a cost line, it is an externality: the damage from abuse lands on the people already paying, because a burned exit address degrades their service, not your margin. Once that is true, the sizing question stops being "how much value before they pay" and becomes "how much unverified usage can sit next to the paid product before it hurts it".

That lands close to the outcome gating others described, but for an unrelated reason. The allowance only has to cover proving the thing works end to end: get the configuration profile, import it into a standard client, complete one successful connection, confirm routing and DNS behave as expected. Volume after that point adds nothing to the buying decision, it only adds exposure.

The other thing I would look at before changing your number: for any product with a real setup step, config import, credentials, a DNS change, an API key, most of the loss is usually in the setup funnel rather than at the cap. If people are abandoning between signup and first successful use, the limit is not what is costing you conversions, and moving it just changes a threshold nobody reaches. Instrument those intermediate steps first. The cap-hitter conversion signal GregoryScottHenson describes is the right metric, but it only carries information once setup is no longer the dominant drop-off.

Treat the free tier as a customer acquisition cost line, not a fairness question, and sizing gets easier. The number to watch is what share of free users hit the cap and what share of those convert: if almost nobody reaches it you're leaving money there, and if they hit it in week one and vanish they never got to value first. We set ours just past the first real outcome, then raised it twice because cap-hitter conversion stayed high, which told us the cap was buying activation rather than blocking it.

I believe a free tier should deliver enough standalone value to drive high user retention on its own.

The pro tier shouldn't just be an arbitrary volume cap; it should sit at a point where your most loyal free users experience a natural point of friction or a compelling 'value unlock'. The goal is to make upgrading feel like a seamless transition that makes an already great habit even more powerful, rather than a jarring punishment for using the tool.