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 struggle with this all the time. I wish there was a formula to follow on this, but I think it depends on the tools.
That’s a solid way to think about it—free content builds trust, and paid is where you go deeper with more personalized value. I think the balance usually comes down to giving users a complete basic experience for free, but keeping convenience and advanced features as premium.
In my case working around anime users, I’ve noticed people stick when the core experience is simple and useful first. Things like easy access, clean UI, and smooth playback matter more initially. For example, setups like Anilab focus on that basic experience, and once users find value, it becomes easier to think about what could be worth paying for later.
I've been giving out 15+ things for free. First I build trust then make it paid. But I havent decided when to switch yet.
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.