Drop Your Free Tier

“Drop your free tier” should be for bootstrapped SaaS apps what “Charge more” is to consultants: a reflex, a sanity check, a default choice.

February 20th, 2017   |    By: Matthieu Varagnat    |    Tags: Growth, Bootstrapping, Customers, Planning, Product/MVP

If you’re bootstrapping your SaaS, you should drop your free tier.

By doing so, I was able to double the revenue growth rate of my Slack app Smooz, while reducing the amount of work required to maintain my app and support my customers.

“Drop your free tier” should be for bootstrapped SaaS apps what “Charge more” is to consultants: a reflex, a sanity check, a default choice.

There may be exceptions, but only for well thought-out reasons. Instead, focus on attracting paying customers. This article is based on hard-learned lessons, from the mistakes I made while launching and growing Smooz. Recently, several entrepreneurs asked my opinion about their pricing structure, and were about to fall into the exact same traps that I fell into.

Why we fall for ‘Free’ tiers

After a bit of introspection (something like “Why was I so stupid???”), I identified the following key mental mistakes I had made when I first launched with a free tier.

Free tiers are attractive for a number of reasons, but the main one might be our ego.

We are afraid that no one will use our service. After spending a few weeks, or even month, on an MVP, it would be most frustrating and embarrassing if no one used it. Instead, we want a large, growing user base, even if it means attracting free users.

There are plenty of counter-examples in which the freemium business model works.

For example: Dropbox and Slack both have a huge amount of users using the free version of their product—and they generate huge revenue from a small percentage of paid users. Trello was acquired for an amount ($400M) disproportionate to their revenue ($19M ARR), placing a high value on their free users. So, why not follow their path?

Free tiers can create immense value when virality accelerates growth or network effects lock users in. However you need to be prepared to manage a large user base, which can require significant resources. While it may be a viable trajectory for venture-funded companies, this post is intended for independent developers, typically solo or in a small team, looking to generate revenues with a SaaS app. If you used Michael Buckbee’s framework to find your idea, you read Clifford Oravec and Justin Jackson, and IndieHackers’ newsletter is the best thing that happened to your email inbox since Slack launched, read on, this is for you.

Underestimating the effort it takes to become an active user.

Visitors need to understand the value proposition and how it can solve their problem, compare it to the competition, convince other stakeholders, and so on. They also have to try the app and follow onboarding. Active users of your services have already invested a lot of mental energy in it. You may overestimate the relative importance of the monthly fee and the percentage of users you would lose if you asked them to pay.

The dangers of free users

Taking on free users can impact a small team in several negative ways. It is especially true for a solo entrepreneur, who has to do everything sequentially.

Handling support tickets from free users.

Bugs will happen, and users will be confused by your onboarding and your UX. As a result, you will receive support tickets (and you may find that free users fill the most tickets). So, how much time are you willing to allocate to them? You can’t totally ignore them, since A) you still love them, because they use your product and you are thankful for that, B) they might level up to premium if you care and nurture them, and C) they can give you a bad rep if you don’t.

Handling feature requests from free users.

You will most certainly hear “I just need this feature to start paying for your product”. Don’t be fooled, this will most likely not happen. If your core product doesn’t address a pain point they have right now, chances are additional features won’t either. People giving this kind of feedback might even think they are being polite “It would be rude to turn him down and tell him I don’t need his product. Let’s find an excuse, like a missing feature”.

Note: Obviously, you should still take note of the feature request. User feedback is still the best way to prioritize new features. For example, I added features to Smooz (to open several shared channels across two Slack teams, and to invite more than 2 teams in the same shared chatroom) when they were requested by paying users. The issue is that feedback from could-be-users can be very misleading.

Unfocused marketing.

Users pay because they have a well-identified problem that your app solves — reciprocally, free users may be outside of this perfect fit. If you want to attract a large number of free users, you may be inclined to dilute your pitch and marketing copy. The worst case I witnessed was a B2B app, with a great problem to solve on a narrow (but lucrative) vertical, brainstorming B2C-like marketing strategies to attract large number of free users. Also, estimating acquisition costs, lifetime values, and planning marketing strategies gets harder when the conversion rate to premium is yet unclear.

Less resource for growth.

Too many free users means more time and resources allocated to maintenance, hosting and customer support. This means fewer resources for development of new features and for marketing.

Worse retention.

I don’t want to generalize too much, but Smooz free users don’t stick around for long on average, while paying users have a very high retention. Having a good retention is the basis of healthy growth, even if it means hurting the acquisition rate in the short term.

So, What should you do instead?

Just drop the free tier.

As mentioned earlier, users already commit time and mental energy to your app. Moving to paid-tiers-only may reduce the total usage by less than you think.

Lower the entry barrier.

If your main plan cost $29 per month, for example, you may have used a free tier as a necessary step, because starting at this price point may turn too many users away. Instead of dropping the free plan, you could replace it by a $9 per month fee.

Implement a free trial.

If you drop the free tier, savvy users still want to see the value demonstrated without initial commitment. A 15 days trial, no credit card required, is fairly standard, expected and efficient. (A very restricted free plan could work out like a free trial, but with the drawbacks mentioned earlier, and more frustration).

Consider alternative revenue structures.

Monthly income is loved because of its predictability and large lifetime value. However, if you keep a free tier because the core value delivered by your service is not very suited for such a model, there are other healthy business models to consider, such as one-off payment or consumption-based pricing.

Note: Jason Cohen has a great video on this topic (between 13:00 and 23:00, but the rest of the video is equally awesome for bootstrapped entrepreneurs).

Moving Forward

When I started looking for ways to monetize Smooz, I started with a very generous free plan. One shared channel could be created for free, and paid plans with more shared channels started at 19€/month. Some users did convert, but the free plan ended up being sufficient for 90% of the users. Upselling from free to paid plan, or from one plan to another, required much hand-holding, negotiation and even some discounts.

I changed the pricing to 6€/channel per month. This ends up being cheaper and more flexible for paying users, while dropping the free plan.

From a quantitative point of view, usage has essentially not been impacted by the change, because only paying users had a really healthy usage of the app. The revenue growth rate doubled, while the acquisition rate was divided by two. This is a trade-off, obviously, but it was what I was looking for.

In addition, on a qualitative basis, up-sales are much more fluid and require very little involvement and back-and-forth, not only because the step is smaller but also because it is an upfront deal.

Also shared on Medium.

About the Author

Matthieu Varagnat

Hi, my name is Matthieu, I am an independent developer and entrepreneur, father of two wonderful girls. I make Slack apps and Messenger bots and I write mostly about conversational UX. I created Smooz.io to help Slack users collaborate seamlessly across teams using shared channels.

Discuss this Article

Unlock Startups Unlimited

Access 20,000+ Startup Experts, 650+ masterclass videos, 1,000+ in-depth guides, and all the software tools you need to launch and grow quickly.

Already a member? Sign in

Copyright © 2024 Startups.com LLC. All rights reserved.