That's the number of users who are paying. He mentions that he has over 100K total users.

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?

Very small absolute changes in that metric are very large relative changes. A conversion rate dropping from 1% to 0.7% is—as you point out—a 30% change in that metric. Or, put in different terms, a drop from 1,000 paying customers to 700 is material and more than a "very small change".

> only ~1% of users are paying, it seems like very small changes in conversion rate could make or break the business.

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.

That's not a real risk. That's an outcome. A risk is something that LED to that drop in conversion. It could be a competitor coming in with the same feature set, or something else. But a drop in conversion is not a risk, it's an outcome.

The risk part is the small margin that means you can't survive small bumps that lead to a drop in conversion.

as the person who responded above me noted, that's not a small margin at all. That's a huge relative change.

I'm not talking about the previous posters 30% drop being a small margin. I'm saying that 1% paying customers is a risk and it's likely to get lower than that, the more exposure it gets.

First, why is 1% paying customers a risk? That's actually a fairly average/normal conversion rate for a freemium product. Trello, I wager gets way less than that.

Second, why is it likely to get lower the more exposure it gets?

I'm not an expert. I've never ran a SaaS business with a freemium model (I have ran SaaS businesses with other pricing models).

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...

We are paying $5000 per month to GCP and $1000 per month to Amazon, we've 300 users paying $300 a month each. Stack : Ruby, Go, PHP (for some integration), JavaScript (Stuck on Angular v1)

7% on hosting revenue sounds like a great accomplishment but what's relatively a good ratio to look at?

So what is normal in the SaaS world? I am at 5% today, and I try but not focus on costs. Around 5% it seems hard to care TOO much...

We're at ~10% and are just starting to care. We're looking at some infrastructure changes to bring us closer to 4%.

Well it makes sense to care more as you grow for sure.

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...

Adding a data point: we're at 1.5% for 6 figure monthly revenue.

That seems very good. Are you on a popular cloud (AWS/GCE/Azure), colocated, or running your own servers?

AWS

We're just over 2%, all in AWS costs.

What revenue range (5 fig, 6 fig?)

While, as others have pointed out, that with 100k non-paying users the $1,600 figure makes more sense. Your example still makes no sense to me, what are you _actually_ doing with all that server power?

Can't speak for xstartup, but if the dataset is 100+ GB then EBS, S3, etc start to cost real money. I host an application on AWS for a single customer with 10 active users which costs about $1500/month because there are several TBs of data and the nature of the application needs a lot of CPU and RAM. In other words, it depends on the use case and data size.

What? I have a 16TB raid that only costs 800$ a month. You should look into how you store that information.

Or stop making assumptions with very little information. That is really my point, but I didn't think it needed to be said explicitly.

I've seen burnt coffee that was roasted less than this.

Yep, that's right. We've not investigated cloud costs at all. If only, I get to have some calm days when my hair is not on fire. Maybe I just suck at development or need to hire really good dev ops team. For now, just single developer.

I've read a good book that taught me some good ways of managing time. 7 Habits of Highly Effective people

We just have really low latency requirements which matter to the customers we serve. And several TBs of clickstream data on which we perform real-time analytics. This is why we rewrote the main request server entirely in Go while we kept the frontend API in Ruby.

Yeah there's definitely some weird engineering decisions there. I think maybe we just don't have all the information. But I guess this is another example of why that stuff just doesn't matter when you're growing your business.

I don't think its a weird decision at all. They support almost 50 editors and are likely to add more.

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.

And note that's after cutting that bill in half by moving off AWS.

The $1,600/mo on servers is mainly because:

* 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...)

We don't know the full stack powering this and there are 100K users/month.

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.

100k is not a lot. at all.

The article mentions 100k users.

It's you. He has 100k users.

That jumped out at me too.