That raises an issue with this sort of model that I've never really understood: if only ~1% of users are paying, it seems like very small changes in conversion rate could make or break the business. Suppose the conversion rate goes down by just 0.3%. That would be a 30% reduction in revenue while you still have to run the infrastructure to support all the free users who didn't convert. Would the business still be financially viable? What's the best way to manage that risk?
Second, why is it likely to get lower the more exposure it gets?
But, everything I've ever read on the subject indicates 1% is either bare minimum or too low. [1,2]
>Second, why is it likely to get lower the more exposure it gets?
In my experience the more hype you get, the lower your conversion rate all other things being equal (in my case conversion rate after free trial, vs freemium) because people who had to search you out to find you are more likely to convert than people who are just checking out the hottest new thing they saw on HN.
That's obviously not always true, and it may not be true in their case, but if I were the CEO, I'd be very focused on increasing my conversion rate.
1. https://hbr.org/2014/05/making-freemium-work 2. https://techcrunch.com/2012/11/04/should-your-startup-go-fre...
Agreed. 4% to 5% seems to be the minimum for this sort of model to sustain and not die.
> Chris Anderson in his book “Free” explains that Freemium works on the 5 Percent Rule - where 5% of premium customers support the remaining 95% of free users and also the cost of servicing the 95% is close to zero.
Source: https://www.chargebee.com/blog/freemium-business-model/
When Dropbox launched they were surviving on their 4% of users who had converted from free subscription. Now their conversion rate is around 25% which is very impressive for a fremium product / service.
Shaving 6% off a 10k a month company is $600 which is nice but not a game changer. Shaving 6% off a $1 mil a month company is $60k a month, which is a nice bonus for someone...
If you were to port the entire application to each editor's idiosyncratic plugin API, it would be a huge scaling issue for them.
Instead, if you make your application standalone and multiplatform and then turn the plugins into thin controllers to connect the IDE and the application, you save yourself a whole lot of development time.
* high volume of incoming requests from plugins sending heartbeats (https://wakatime.com/blog/23-how-to-scale-ssl-with-haproxy-a...)
* keeping all the metrics cached in real-time, many background machines dedicated to only this
* data storage & reads - if you change your Timeout Preference need to re-cache your coding activity quickly (https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-ac...)
There have been a lot of great points in reply to this and I would like to add that part of this cost may be to help perception. A service like this that feels/is slow can die pretty quickly if the perception of the service is that it doesn't work as well as it should.