How do you decide what features should be free and what should be paid?
Let me start from the creator’s perspective:
I personally don’t have a product (apart from hiring people for creative work or offering personal consultations).
But as a creator, I constantly share content, insights, and information, value that helps me build trust (for free). Based on that perceived expertise, people eventually decide to work with me (a paid service).
So some things I share for free to eventually move toward a paid collaboration.
Personally, it’s sometimes hard to judge when I might be giving away too much for free.
And I assume it’s similarly tricky for builders.
You want users to try the product, but then comes the question of paid features, or a trial limited by time or usage.
How do you decide which parts of your product or service remain free, and which become paid?
When I share content publicly, I usually provide generalised advice. But when it comes to a specific case or a tailored strategy that requires a personal approach, that’s where it becomes paid.
Replies
I respect this approach going paid only forces real discipline around value and avoids the free users draining resources trap .
My latest app, I give all features free with limited amounts, or access times. If need more, then have to upgrade the plan.
The benefit of this strategy is user has a chance to try all features and then decide if this product is what he wants.
The key is to offer something free that is easy to consume, and to charge for something that is hard to consume. For example, most successful YouTube creators produce dozens of high-quality one-off videos every year. But if you want a 25-hour course on some deeper subject (how to play piano, speak French, etc) this is a different medium entirely. It is hard to consume vs easy to consume. So you can charge for this, because trying to play piano or speak French via random single YouTube videos is almost impossible. You need an indepth course, which means you need to pay money.
The framework I've seen work best on SaaS products I've built: free = value demonstration, paid = value delivery.
Free gets users to their "aha moment." Paid removes the ceiling once they're already invested. The mistake I see most often is paywalling the aha moment itself — that's what kills conversions.
Tactically: look at which features drive retention at week 4. Those are your paid features. Features that drive activation in week 1 should be free or nearly free.
The other dimension is cost. If a feature has meaningful COGS per user (AI calls, storage, compute), it can't stay free at scale regardless of how it fits the above model. Architecture matters here — I've refactored billing layers on several SaaS products to support hybrid free/paid at scale. It's non-trivial to do right without the right backend structure.
Happy to dig into specifics if anyone's wrestling with this. I'm a full-stack dev (NestJS/Node/React) who works with early-stage SaaS founders — zeescript.com
Going thru this calculus as we speak; I'm planning a product launch with heavy S3 storage. First launch will be LTD in 4 tiers to gauge interest and build a user base. I need to be very careful about hemming in all data egress leaks and making sure tier limits are reasonable, balancing average costs and making sure I've left myself a workable runway of 3 years or so. Then it comes down to add-ons and how to price them so users hit reasonable limits and feel compelled to upgrade to monthly add-ons. Storage and transfer is of course the main cost driver, but I've decided that certain things like seat limits on teams can drive upgrades, even though they're technically arbitrary limits. Honestly, bigger teams use storage faster and hit upgrade targets sooner, but a 5 seat limit on tier 1 might drive more users to invest in higher tiers earlier. Figuring out this exact math is the biggest reason I haven't launched yet.
This is a very hard question answer, but it generally boils down to your product and goals. We are currently offering a paid lifetime deal for our product. As we are early stage we want committed users to direct development of the product rather than volume, we are also self funded at this time so paid allows us to cover support costs and generate revenue to extend our runway.
I think as a creator, your strategy seems good, sharing your knowledge for free certainly works to help build credibility and attract customers, including case studies of results you delivered for your paid clients would perhaps lend to more paid conversions.
First of all, there is nothing free. When you give something for free, you are actually incurring an advertising cost. My view is, a user should be able to discover enough of the features to help them decide whether to use the app or not.
As a builder, I'm okay keeping things free as long as it does not increase the cost notably.
We decided to use limit certain features to our site that offered extensive value to the customer. Easiest way to decide is asking customers what they found most valuable and what features they would pay for.
Been rotating between Lenny's Podcast and 20VC lately. Anyone have recommendations for more product-focused ones?
For my app (TokenBar, a macOS menu bar utility that tracks AI token usage), I went with a simple one-time purchase. $5 for Basic, $10 for Pro. No free tier, no subscription.
My reasoning: the app solves a clear, specific problem (you are paying for 5+ AI tools and have no idea what you are actually spending). If someone has that problem, $5 is an easy yes. If they do not have that problem, a free tier would not convert them anyway.
I think the "freemium" model works when your product has network effects or when users need time to discover value. But for a simple utility tool, I would rather charge a fair price upfront and skip the whole conversion funnel. Fewer support tickets from free users, no pressure to gate useful features behind a paywall, and the people who buy it actually want it.
The hardest part was resisting the urge to add a subscription. Recurring revenue sounds nice on paper, but for a utility app that runs locally on your Mac, a subscription feels wrong to me as a user, so I did not want to do that to others.