7 ms·

Is it me or is it nuts to be paying $1,600 a month on servers when you have just over 1000 users? Seems like something that could be run on a $50-$100 VPS.

by kasbah 9y ago

Linell 9y ago
The article mentions 100k users.
deleted 9y ago
[deleted]
ryeguy_24 9y ago
That jumped out at me too.
blaisio 9y ago
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.
- cptaj 9y ago
  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.
jonas21 9y ago
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?
- basseq 9y ago
  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".
- AznHisoka 9y ago
  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.
  - learc83 9y ago
    The risk part is the small margin that means you can't survive small bumps that lead to a drop in conversion.
    - AznHisoka 9y ago
      as the person who responded above me noted, that's not a small margin at all. That's a huge relative change.
      - learc83 9y ago
        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.
        AznHisoka 9y ago
        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?
vanesa- 9y ago
It's you. He has 100k users.
xstartup 9y ago
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)
- awinder 9y ago
  7% on hosting revenue sounds like a great accomplishment but what's relatively a good ratio to look at?
  - brianwawok 9y ago
    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...
    - leesalminen 9y ago
      We're at ~10% and are just starting to care. We're looking at some infrastructure changes to bring us closer to 4%.
      - brianwawok 9y ago
        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...
    - junker37 9y ago
      We're just over 2%, all in AWS costs.
      - brianwawok 9y ago
        What revenue range (5 fig, 6 fig?)
    - 9y ago
actionscripted 9y ago
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.
- graphememes 9y ago
  100k is not a lot. at all.
cookiecaper 9y ago
And note that's after cutting that bill in half by moving off AWS.
welder 9y ago
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-and-nginx 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-activity https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-ac...)

Is it me or is it nuts to be paying $1,600 a month on servers when you have just over 1000 users? Seems like something that could be run on a $50-$100 VPS.

by kasbah 9y ago

Is it me or is it nuts to be paying $1,600 a month on servers when you have just over 1000 users? Seems like something that could be run on a $50-$100 VPS.

Linell 9y ago

The article mentions 100k users.

deleted 9y ago

[deleted]

ryeguy_24 9y ago

That jumped out at me too.

blaisio 9y ago

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.

cptaj 9y ago
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.

jonas21 9y ago

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?

basseq 9y ago
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".
AznHisoka 9y ago
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.
- learc83 9y ago
  The risk part is the small margin that means you can't survive small bumps that lead to a drop in conversion.
  - AznHisoka 9y ago
    as the person who responded above me noted, that's not a small margin at all. That's a huge relative change.
    - learc83 9y ago
      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.
      - AznHisoka 9y ago
        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?

vanesa- 9y ago

It's you. He has 100k users.

xstartup 9y ago

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)

awinder 9y ago
7% on hosting revenue sounds like a great accomplishment but what's relatively a good ratio to look at?
- brianwawok 9y ago
  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...
  - leesalminen 9y ago
    We're at ~10% and are just starting to care. We're looking at some infrastructure changes to bring us closer to 4%.
    - brianwawok 9y ago
      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...
  - junker37 9y ago
    We're just over 2%, all in AWS costs.
    - brianwawok 9y ago
      What revenue range (5 fig, 6 fig?)
  - 9y ago

actionscripted 9y ago

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.

graphememes 9y ago
100k is not a lot. at all.

cookiecaper 9y ago

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

welder 9y ago

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-and-nginx 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-activity https://wakatime.com/blog/27-fill-the-gaps-in-your-coding-ac...)