How do you decide what features should be free and what should be paid?

I have a very generous freemium set up. For the paid version, it's all about power users: when they want to use more of the tool, they pay for it to unlock it. Unfortunately, it means a lot of users, not many willing to pay. I was considering an offer for 100 users or so for X price forever... but the app is hard to maintain to sustain it with that.

This is very critical point, I believe also it comes from the pricing strategy and the type of the product. SaaS for example with Freemium model, normally any features that is in the core workflow of your users should be priced and offering free features that help and improve the end-to-end experience but is not the core one.

Also, you can offer high-used feature on usage level like number of analyzing documents is X and after X you need to upgrade to create the hook

There are a lot of criteria and factors that help you decide but I think it should start from startup and product vision, then your pricing strategy and moving forward

Great question.
My rule is usually simple:
free = enough value to create trust
paid = the part that creates direct outcome, saves serious time, or removes complexity

People should be able to feel the value before paying. But the real transformation / execution is where paid usually starts. For builders, I think the hardest part is not “what can I charge for?”
It’s what should stay frictionless so adoption can happen first.

For me the line is blurry and I don't think there's a clean answer. The mental model I keep coming back to is: free should create/show the problem, paid should solve it.

For content/services like yours, free builds the belief and generates the trust that you can help. Paid is the actual help. You're not giving away too much as long as the free stuff makes people want the paid service more, not less.

When I build products I take a similar approach, FREE should be generous enough that users get real value and trust the product, but the moment they want to go deeper, faster, or at scale, that's where paid comes in play.

I think the way you described it is actually pretty close to how I look at it too.

For me it comes down to this: the free version should be genuinely useful on its own, not just a teaser. Someone should be able to use it and get real value without feeling forced to upgrade.

The paid side is where you go deeper more control, more power, more customization, or anything that saves serious time. Basically the stuff that moves from “this is nice to have” to “I actually rely on this.”

I also try to think in terms of respect. If people feel like you’re holding back basic functionality just to push a subscription, they’ll bounce. But if they feel like the free version helped them and the paid version just makes their life easier, they’re way more open to it.

It’s definitely a balance though. Still figuring that line out myself.

@busmark_w_nika IMO everything must contribute to the main business pipeline, even "free" stuff, are serving the "paid" parts. So, any part that is desired by many, won't put a lot of cost on your table, and can act as "lead magnet" can be free, but well attached to the rest of the paid services/features, so it can convert users to paid clients.

As a new developer in the Crypto Tax space promoting Privacy - full disclosure is important to me. Therefor, providing users a privacy policy and access to all their calculations and reports is free. The only paid part of the app is printing final report PDF's and CSV's. They can use the software and manually transfer results to their tax submissions - and test results against their current methods. I am confident once they have all their data encrypted and classified, next year's taxes are a snap using my app. Plus, I am ultra competitive on price and security. For me accuracy matters too - users need to be 100% satisfied before they buy - because that's what I would want.

So - ask yourself the question first - what would I pay for this and where is the benefit? Then, be open with users.

This is what i consider when i want to determine pricing and free features.
If the components are already free in some products, i usually make them free too, and if i added new features on to them then the new features will be available as a paid option.
Another metric i use is the quantity usage of the feature, the more the usage increases, the more the user will have to pay.

I'm still new to this, so i'm open to recommendations.

I usually think about it like this: free should show the value, paid should deliver the deeper outcome.

Free features should let people understand what the product does and actually get a small win. If users can’t feel the value, they’ll never pay.

Paid features are usually the things that either save a lot of time, unlock more power, or scale the results. Basically the parts that become important once someone is already getting value.

For example:

• Free → try the core idea

• Paid → do more of it, faster, or with better results

I also try to avoid making the free version feel “crippled.” It should still be genuinely useful. If people like using it, upgrading becomes a natural step instead of a forced one.

It’s definitely a balancing act though sometimes you only figure it out after watching how users actually use the product.

One great idea I'm bouncing around at the moment is to offer paid subscription features for free but with limits. I believe the freemium model greatly increases conversions, and you can see examples of this in applications like Vercel / Expo, even Microsoft has a "only pay when you cross a limit" feature.

I think this works great, because it allows users to build up trust as you mentioned Nika, but it also increases the value proposition. I'd be more willing to pay for something personally that's already working for me.