How our freemium plan failed

It sounds like the freemium experiment was a success (11% conversion rate), and the failure was your lack of preparedness to scale to support the extra load it brought with it.<p>The 60 customers that were lost during that time period - were they pre-existing customers from before the freemium switch, or new customers? Did they leave because the technical issues or because they saw the freemium version and decided they didn&#x27;t want to pay any more?

One of the counterintuitive things I learned fastest after entering the workforce is that there is often an inverse relationship between amount of money being paid for a product and the level of support demanded from the users. Almost without fail, our least difficult clients pay the most money, and our lowest value customers make the most demands.

We went through this transition at CircuitLab <a href="https:&#x2F;&#x2F;www.circuitlab.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.circuitlab.com&#x2F;</a> -- now we have free demos that don&#x27;t support saving to the server, so they&#x27;re almost free in terms of server resources. Also, don&#x27;t allow forum posts from non-paying customers.<p>As the article hints, the real limit isn&#x27;t computing resources (CPU&#x2F;storage&#x2F;etc), but people resources. Committing these resources to non-paying customers is generally not a winning proposition.<p>Upfront-card-capture free trial periods and liberal money-back guarantees give your customers the zero-risk ability to guarantee that a product is a win-win, but filter out people who don&#x27;t take your product seriously enough to consider paying for it.<p>I&#x27;d advise any founders working on SaaS products to provide some sort of free trial mechanism, but probably less than they imagine!

Is there anything in this experience that&#x27;s actually a result of a Freemium model?<p>It sounds like any usage spike would have resulted in the same outcome. If you had been featured in Oprah&#x27;s &quot;Favorite Things&quot;, and ended up attracting the same number of users to a <i>paid</i> plan, which of the events would not have occurred?<p>1. Server resources would have been strained.<p>2. Engineers would have been reassigned to scale instead of features.<p>3. Existing customers would have churned as a result of inability to scale.<p>The only notable difference is that you did it to yourself. On the flip side, it also enabled you to turn it &quot;off&quot; by limiting the free account, which you would not have been able to do if the users were from a referral source expecting to pay for account anyway.

We&#x27;ve had to deal with an onslaught of of free users at our startup <a href="https:&#x2F;&#x2F;glyphs.co&#x2F;" rel="nofollow">https:&#x2F;&#x2F;glyphs.co&#x2F;</a> quite a bit over the past few weeks: last week we took in something like 4k new user accounts.<p>I&#x27;m definitely a big fan of freemium, and specifically I really like limiting accounts by features (less by usage), but I think it&#x27;s 100% imperative to control the rate at which new users are given access to your system. We&#x27;re currently in beta which makes it easy (by only allowing users at our pace) but I think in your case (given the amount of processing required) it would have been very advantageous to build a line for the free account and let people wait for a bit. That builds demand, lets you control user-flow, and people who are very interested can pay to skip the line. Anyhow, just my thoughts, obviously every scenario is different and you guys know this area best.

I don&#x27;t think this is an indictment of &quot;freemium&quot; so much as the decision-making around it.<p>Also, there&#x27;s a misnomer that you&#x27;re supposed to link pricing to features or usage. No, you link pricing to the customer&#x27;s ability&#x2F;desire to pay. Sometimes this correlates with features and pricing but often times not. Multi-user access is a good example of a feature that naturally appeals to a company with resources (i.e., ability to pay). Automatic collections is not.

An &quot;11.5% conversion rate&quot; is a bit disingenuous. Their advertisement method attracted users who were not &quot;actually eligible to even think about becoming a paying customer&quot;. I don&#x27;t think you can so easily exclude them. Put them back in and you have &quot;over 1,000 free accounts&quot; and only 53 that upgraded.<p>Assuming &quot;over 1,000&quot; means &quot;over 1,060&quot; then 53 paying accounts actually means &quot;less than 5%&quot; which fits with their assertion that &quot;the average B2B conversion rate is around 3-5%&quot;.<p>While I applaud converting 461 &quot;potential paying customers&quot; into 53 paying customers, the 11.5% rate seems more like an internal metric. It&#x27;s important to focus on what you can achieve and so segmenting out those with the requisite &quot;subscription revenue&quot; to be able to convert is useful for refining internal goals, but there is a reason why the average conversion is so low: you always get customers who can&#x27;t pay.<p>If other businesses were excluding those customers the quoted average would be greater than 3-5%.

I think also freedom is not free.<p>I often download a 15 or 30 day trial of some program and that sounds like a lot of time, but it can take a day or more to really evaluate something and I need to multiply that against some guess of the probability we will really adopt it. Well we have lots of tasks that have a 100% probability of &quot;must be done&quot; and those are more important and then the trial ends and I forget about it.<p>If you make somebody put some chips in the pot upfront it makes them more serious, like they not only have something to gain but also to lose.

For sure this is interesting to think about. Is all the work I need to do for the unpaid people who may or may not ever pay me a penny worth it to get a few more users?<p>if the &quot;work&quot; is just spinning up some new AWS nodes, the math is easy. If lifetime value of a free guy &gt; cost of AWS node, do it. If &lt; cost of AWS node, don&#x27;t do it.<p>If the work is lots of staff related hand-holding - then it depends. If your staff is at 100% capacity and you need to hire more staff, it is closer to the AWS example above. If you have staff sitting around doing nothing anyway, then maybe it is &quot;free&quot; as in an already sunk cost.<p>In their case it seems like they had some engineering flaws in their system (who doesn&#x27;t), that made the scaling up part harder. Good to think about how to scale up early so you don&#x27;t hit a wall.

This is a poster child for the value of raising money vs solely bootstrapping (I hope DHH doesn&#x27;t downvote me!) It appears this added $60,000 ARR. I&#x27;m not sure how big the market is (TAM would be all Stripe subscription users?) but assuming it&#x27;s 10x of what they found in just 60 days and growing (as Stripe is growing) Therefore are you looking at $500,000 to $1 mil more per year if properly resourced to go after this opportunity? Raise $1 million to staff up for it; the good news is you have real data now.

Did you think about technical solutions to this? You list one obvious one (limiting the Stripe import for free plans to the 30 days you actually display), but the other one I would&#x27;ve looked at immediately is to avoid storing the raw data for free plans entirely, compute your metrics on the fly, and store only the computed metrics. 1000 customers * 30 days * 25 metrics (based on your homepage) * 4 bytes&#x2F;metric = 3MB, which is trivial for any database to process.<p>In general, I think most engineers these days overuse databases. At Google, common wisdom was &quot;never, ever hit the disk during routine serving&quot;, and when I was in the financial industry we&#x27;d regularly process the NYSE TAQ data (50GB, about 2B trades) on a single machine nightly.<p>It&#x27;d be really, really nice to have growth gated on technical problems. :-)

You can&#x27;t do freemium unless you are prepared to upsell the crap out of your free users.*<p>Otherwise you&#x27;re wasting your time and your users time.<p>* Unless you want to eat the costs for a few years. In that case you need to really develop your brand to become top of the line in your market.

Additional 1k accounts crashed production servers? I think fixing the software stack is much more important than business strategical adjustment.

I think, the freemium model works best, when the resources needed for one additional customer (including computing-power, storage and support) are relatively negligible.<p>Many companies operate the freemium model with much less than 11% conversion rate -- but the additional customers they have to carry with the others are not so a heavy burden.<p>The advantage of the freemium model is faster scaling and adoption of the service -- but with the cost of an additional burden ... and you have to know, if your business can carry the weight or has to do differently.

I&#x27;m sure they made a real development investment to add Freemium features on top of their free trial. At Cronitor we recently moved in the opposite direction -- from a limited freemium model to a free-trial -- for similar reasons.<p>Our free plans were limited to an extent that they didn&#x27;t blow-up our service. Our primary concern was that as we&#x27;ve built out our product, introduced more advanced features, and signed bigger customers, the risk that a free user could degrade service for paying customers no longer seemed worth it. We considered isolating free users in a separate silo but maintaining that infrastructure also didn&#x27;t seem worth it.<p>Ultimately these are hard problems to test because rolling out a change like this requires a lot of work. Even if you release it via b-test you&#x27;ve already made a real investment to get that far.<p>For those curious, we are keeping the free trial model but we do hope to continue improving trial conversion.<p>Edit: For clarity

I have witnesses several companies scale customer acquisition too quickly, scramble to get their ducks in a row, become addicted to the growth due to their bloated operations and eventually collapse under the weight.<p>This doesn&#x27;t just go to being prepared to handle growth, but realizing that most customer acquisition strategies either decay over time or reach a point of diminishing returns, and putting yourself in a position where you need growth and volume to survive and betting on your existing customer acquisition is a formula for failure.<p>Like all thing, Growth is neither good nor bad on it&#x27;s own, and should never be more than a means to an end.

Freemium is definitely hard. We do this with Quill Engage (quillengage.com) for Google Analytics reporting and it certainly took us a long time to fully understand the workload associated with maintaining a free product while trying to support our main paid product.<p>For what its worth, we&#x27;ll be signing up and trying out BareMetrics shortly. I love what we&#x27;ve seen of your product so far and look forward to seeing what your team has delivered.<p>One other comment -- I love how you pulled in the output of your product to so clearly support the point of your blog post. Not a bad job selling your product while discussing technical issues :)

&gt; <i>in two years ... grew the business ... to over $30k&#x2F;mo in revenue</i><p>Combined with the fact that your About page shows 5 people, this is easily the most interesting part of the post :)

Good learning and write up. Running a bootstrapped product myself, I learned that the best thing to do is to offer a Free Trial but never unlimited free account for B2B businesses like these. Also, trying to restrict with features never really works out at the end as people will always find a way to put stress on your system along with tons of support issues. Just offer a free limited trial with ALL features and when the trial ends, ask them to upgrade.

I think David Heinemeier Hansson and Basecamp would love this.