At what point does free usage become too expensive?
I'm starting to run into a problem I didn't really think about when I launched.
Most of my users are on the free plan.
Which is fine. I actually want people to be able to try the product without pulling out a credit card.
The problem is that "free" isn't actually free for me.
Every user creates some cost somewhere.
Database storage. API requests. File storage. Bandwidth. Emails. Background jobs. Third-party APIs.
When I had 50 users, I barely noticed any of it.
At 500, I started paying attention.
Now I'm looking at what happens if usage grows another 10x and I'm realizing that I can't just keep adding free users forever without understanding the unit economics.
The confusing part is that I don't want to put artificial limits everywhere.
For example, telling someone they can only use the product 5 times a month might make my costs predictable, but it could also prevent them from getting enough value to ever become a paying customer.
At the same time, I don't want someone using a feature heavily for free while I'm quietly paying more to serve them than they will ever pay me.
So I'm trying to figure out where other founders draw the line.
Do you put limits on the free plan based on actual infrastructure cost?
Do you let free users consume as much as they want and rely on a small percentage converting?
Or do you only restrict the expensive features?
I'm especially curious about products where the cost per active user isn't close to zero.
At what point did you realize your free plan was becoming an actual expense instead of just a growth strategy?
Sign in to join the discussion
Don't cap basic usage, just wall off the real cost drivers. Keep the cheap core workflow open so users get hooked, but put strict limits on the expensive stuff like heavy background jobs, third-party API calls, or file storage.
You usually hit this wall when you realize power users are exploiting your free tier to run their own businesses without ever upgrading. Free tiers are meant for evaluation and light utility. Once a user's usage pattern looks like a production environment rather than an evaluation, your free plan is failing its job.