Free vs paid features – finding that sweet spot

Last week, I posted about deciding what features should go into a product vs what features should go into the trash. It got me thinking about how to decide what to include in free vs paid plans.

It's a delicate balance — you've gotta give enough to make it valuable, but you can't give away the farm if you want people to convert to paid.

Here's what I've found. 👇

What do free users bring to the table?

The whole point of freemium, to oversimplify things a bit, is to extend reach, get users, and then monetize those users. Fair enough?

But I think it's important to remember that free users bring more to the table than future money. They're great sources of:

• Word of mouth
• Feedback
• Usage data (use it to improve the product)
• Social proof
• Increased value through network effects
• Revenue (e.g. ads)
• Vanity metrics (yeah, they don't matter much, but they feel good!)

It's important to keep this in mind for a few reasons, not the least of which is so you don't deprioritize them and focus only on paying customers — while understandable in some situations, that can be detrimental long-term.

But the real reason I'm bringing this up here is that it impacts what should be on the free tier vs paid tiers. Want network effects? Then you've gotta include networking features in the free tier. Want feedback from the masses on a feature? Then you've gotta include that feature. Want word of mouth? Then you've got to provide a lot of value in the free tier… but not too much, right?

Your options

Before you decide on what features should be free versus paid, consider a few freemium options.

Honestly, my favorite option is to restrict usage by volume so that power users pay more. But this won't be possible for all products. The reason I like it is that the people who use it most pay the most — it makes sense. It's fair. It's a non-arbitrary distinction.

And I'm not alone:

@simplisticallysimple: Is there a way you can restrict usage based on volume? … This allows people to try for free, but those heavy power users will be asked to upgrade their account. And since heavy users are the most likely to upgrade anyway, you should be able to get some sort of conversion.

@47ng: Do you have a way to limit the usage of your product ? Like rate-limiting or quantity-limiting.

This is the technique used by Slack and Notion, who allow free customers to use the product within reasonable limits, and convert them to paid once they have enough engagement and want more out of it.

For access-limiting (some features only exist in paid plans), it depends how much value you see out of it. The core of your product should be usable for free users, but "surrounding" features (eg: export to PDF, bulk manipulation of data, anything that can make power-users more productive) are good candidates for premium paid features.

Another option that I touched on above is making free vs paid a question of ads vs no ads. We're all familiar with that one, which makes it a decent option, but you've gotta be careful because ads can affect your brand image and UX.

Open-source folks do it by offering the whole shebang for free if the user has the technical capability to host and run it. Users can pay if they don't have (or don't want to spend time using) that ability.

In-app purchases are also an option — buying specific upgrades, for example.

But for now, let's assume you're doing the usual thing of offering premium subscription tiers.

What types of features should be included in free vs paid?

Here are some types of features that should be included in free tiers:

• Features that create network effects. Don't wall these off!
• Features that create habits. Creating a habit in free users not only boosts retention among those users, it increases the likelihood of paid conversion. Include features that make the free tier a part of daily life.
• Features that extend your reach, like sharing and collaborating.
• Features that you're testing, or that need to be optimized. Use the data (ethically).
• Features that promote your product (via watermarks, links, etc.).
• Features that require minimal support.
• Features that are automated on your end so that they don't take your time.

Here are a couple thoughts from other indie hackers:

@vilimas: So in my opinion. You need to know your user base and separate them by categories. Basic and power users. My approach is to monetize power users. Know which features are above basic usage and add them to premium. For basic users constantly add value and hope they become power users. (Or educate and convert to power users)

@chaddeus: I think a good rule of thumb for some products is the point when your app switches from giving helpful, actionable information to doing things for the user. Once you start "doing" rather than "informing" I think that's a good point to start charging.

And here are some types that should be included in paid tiers:

• Features that increase your cost
• Features that increase your support workload. Free users are great, but they shouldn't necessarily get white-glove service. Support them, but don't include features that will get you bogged down working with them.
• Features that users (not you) believe to be worth paying for (duh).

How to find that sweet spot

The bottom line is this: Figure out what is essential. What is absolutely core to your product? That fundamental value of your business should be available to free users because that's what they came to do. Any other features included on the free tier should be paying for their seat on the free tier — literally. The fact that free users have access should in some (often roundabout) way create new paid users.

It's going to take some trial and error, so consider testing it. I'm personally not a huge fan of A/B testing where some users end up paying more, and this would fall into that category, but it's an option. A fairer (but less scientific) way of testing is making your best guess, implementing it, and adjusting as necessary until you hit a sweet spot.

To find that starting point, talk to your customers. And look at what your competitors are doing — they've probably tested it already. But if you go the competitor route, change it slightly and offer something for free that your niche will love — something that isn't free on the competitor's product.

Rubric: Once implemented, change if:

• Free users aren't converting (you're giving too much away for free)
• New users aren't signing up (you aren't giving enough away for free)
• Free users aren't being retained (you aren't giving enough away for free).

Those are obviously oversimplified but they will generally hold true.

If free users aren't converting, there is a question that'll inevitably come up. Should I: A. Add features to make paid more enticing, or B. Restrict features to make free less attractive.

I think we would all agree that adding value is always better than restricting value. But, we'd probably be wrong. There are times that call for restricting value.

Adding value to paid is the right choice when you're building. But when it's already launched, if everyone is content with the free tier, it will take a very awesome feature to get a free user to convert — usually a core feature. So in that case, you're giving away too many features and it's best to cut features.

With that said, cutting that free user's features is a sure way to lose that user. So grandfather them in as a thanks for being earlier adopters, and change the tier for new users.

If new users aren't signing up, or they aren't being retained, you may need to add features to your free tier. It gets confusing if this is happening and free users aren't converting — that might be a situation where you need to add to free and paid or, let's be honest, consider a pivot.

Doing it right - best practices

I'll wrap up with a few tips that might help.

First off, make an initial decision about how you'll do delineate between free and paid before you build the MVP. That way you'll build with it in mind and you won't have to work backwards later.

With that out of the way,

• Don't hide paid features. Show them, plain as day, but disable them and put a little "paid" tag on them. If the user clicks, prompt them to upgrade.
• Add upgrade campaigns. Segment your users and send personalized emails based on how they use your product (or what they use it for). Tell them about the plan that's best for them and why. But don't overdo it, or they'll unsubscribe.
• Add triggers that display upgrade prompts in-app based on particular actions. Again, do it sparingly so that you don't affect the product's UX.
• Put little 'ads', for lack of a better term, around the product that remind the user about the paid tier and give them an easy way to upgrade. Make these unobtrusive.

What did I miss?

Subscribe for more how-tos, tips, and case studies.

The Boot's Trap 🪤

Learn from indie hackers who are in the thick of it

Subscribe