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.

+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.