Recently, we at Weavy announced that we were making a crucial change: In-app Chat, our most popular feature, would be available completely free. Our CEO Rickard Hansson detailed his reasons for making this decision, in which he also aptly pointed out that we’re hardly the first web based company to offer a free plan:
“After all, this methodology is as old as the internet itself and has evolved in the SaaS space to the ever-present “Freemium” model. Under this model, most businesses (including a few other Chat API providers) offer a lower “free” tier. For the end-user, these free tiers are a great way to evaluate the product and see if it fits well within their own productivity stack, and for the business, it provides an easy way to lure in cost-conscious customers.
Of course, these free plans are often nothing to hang on the Christmas tree. They usually come with very reduced functionality or severe limitations on usage, in essence acting more like a technical proof of concept or a free trial than an actual product. There are, of course, exceptions, and at Weavy we hope to be one of the most notable exceptions to the American idiom “free to play, pay to win.”
This struck a chord with me. As someone who has spent several years working in and around SaaS, I’ve heard more than my fair share of pitches for freemium products. Sooner or later, each of these pitches invariably gets to the part where they detail how they plan to use this freemium tier to push a customer to a paid tier.
This is neither unexpected nor unwarranted: businesses exist with the goal of making money, after all. But it’s easy to become overwhelmed by the sheer volume of options and compromises that are often used to differentiate a freemium plan from its paid contemporaries. For product managers just trying to evaluate the best option for their tech stack, this can be a daunting prospect. That’s why today we’re going to demystify the different approaches to freemium offerings, and lay out just what separates a freemium plan from a truly free product.
Before going any further, I think it’s valuable to define what makes something freemium. Freemium is of course a portmanteau of “free” and “premium,” the connotation being that freemium is a premium product offered at the low low price of free. The goal with any freemium offering is to eventually convert a user to a paying customer. This goal is achieved through one of three ways: limitations, metering, or paywalls.
In 1996, when most news outlets were just beginning to take their first nascent steps onto the web, the publisher of The Wall Street Journal did something wholly unexpected: the 107 year old newspaper launched an online edition that required a paid subscription to access any content whatsoever. This is largely considered by most to be the first example of a paywall.
Though there are no doubt exceptions, paywalls exist almost exclusively in the world of content. Despite over a decade of resistance, most major publications that still have a print component now operate on a freemium model that utilizes a “soft paywall.” Under the freemium model, most users are allocated a certain amount of content with the knowledge that access to all content is gated behind a subscription or one time fee. In the world of individual publications like The New York Times or Wired, free users are typically allowed between 5 and 20 articles to read each month, with some premium articles or features (like the crossword puzzle) permanently restricted to paying customers.
On the product side of the equation, content apps like Apple News offer users access to a large selection of content completely for free. But to get the complete experience, replete with digital editions of print magazines and professionally read audiobook editions of longform articles, users have to pay $10 a month. There are countless examples across the content app landscape, and nearly every subscription based content app uses some form of soft or hard paywall, or some combination thereof.
The bulk of freemium offerings you’re likely to find in the SaaS world today operate on a tiered model that is divided by metering or limiting some aspects of the product. For metering, you take a quantifiable part of your product, like say the number contacts in a CRM or the amount of users on a collaboration app, and set up artificial boundaries (or caps) that cannot be crossed without moving on to the next pricing tier or paying an overage. For limiting, you take a feature of your product, like HIPAA compliance or dedicated server support, and limit it to more costly tiers.
Something attractive about these solutions from a product management perspective is that they’re flexible and easy to adjust based on user and usage data. From a messaging standpoint, you can create clear delineation between pricing tiers that can help inform customers on finding the right tier for their needs. From the consumer perspective this approach is logical: the more you use the product, the more you pay, if you’re below a certain threshold you pay nothing at all. Of course, this is assuming a best case scenario, because either by mistake or by malice the structure of these tiers can quickly become needlessly complex or functionally useless.
But before we get mired in how a freemium tier can go wrong, let’s examine some examples of where it’s gone right. MailChimp and Slack have a few things in common: they’re both SaaS tools that have a heavy footprint in the prosumer and entrepreneurial space, they both were acquired in the previous year for incredible sums of money, and they both are lauded for their incredibly fair freemium plans.
To be clear: these plans are still designed to eventually convert as many users as possible into paying customers. But what makes them fair is that they allow users to use their tools with most of their crucial features intact, and with a decently high ceiling of usage before hitting their caps. For Slack, you’re allowed up to 10,000 messages and 10 integrations with external apps for notifications. For MailChimp, you’re allowed up to 2000 contacts and full use of their CRM and email capture features.
Anecdotally I’ve used both Slack and MailChimp’s freemium plans at the ground floor of several early stage startups and averaged 4 to 7 months before having to upgrade to the next paid tier. These freemium plans are generous, and they’re also incredibly out of the ordinary for the space.
As previously stated, the benefit of a tiered pricing model is that meters and limits can be set based on user and usage data. The drawback, if you’re shopping for a freemium plan, is that that data can also be used to severely limit how much can be done before a user upgrades. The most extreme cases of this practice even have their own potentially problematic nickname: crippleware. Or a slightly less problematic nickname: TurboTax.
Fellow Chat API PubNub, for example, has advertised their free tier for years. However, once you look at the limitations: less than 200 monthly active users, no support for SSO or SAML, and no support for custom domains, you begin to understand why their own pricing page describes it as being best to “develop a proof of concept.” When evaluating a freemium SaaS product, make sure to look for the following red flags:
These plans aren’t designed to give users access to premium features while respecting their budget, they’re designed to upsell early and upsell often.
To give you an idea of just how dedicated Weavy was to making In-app Chat a truly free product I’m going to give you an exhaustive list of everything we changed in the API and SDK to prepare for the new price:
The whole point of making In-app Chat free was to make it free. That means:
We did this because we believe it’s the right thing to do, and we’re confident that when people see the value of adding rich, contextual collaboration features into their app, they’re going to want to add more.
