10 March 2020
So I’ve got this idea called Wünderbucket. It’s simple static web hosting for designer / developers who can only write HTML & CSS. I really want to build an app that’s sustainable. And for me sustainable means cheap.
I need a system that:
Seeing as Wunderbucket is cloud hosting, this could get expensive quick.
My model is freemium with Pro plans at $5/mo & $60/year. I’m assuming that we’re going to have 99% free users and 1% pro users (pretty standard SaaS conversion metrics). That means $5/mo has to pay for 100 users worth of cloud hosting costs and be profitable. That’s not a lot of margin.
The dynamics of this business are pretty simple: The lower I can keep our cloud hosting bill per 100 users, the quicker this becomes a self-sustaining enterprise. Here’s how I’m going to design this system so it works for me:
There’s really only three options that are worth considering: AWS, Microsoft Azure, and Google Cloud. They’re all fighting for eachother’s business and they’ll give you secret discounts so it’s pretty tough to choose.
I’m going with AWS because I’m really familiar with their stack. I’ve used Azure and Google in the past and they would do fine too with the features I’m looking for. This is one of those situations where I need to lean on my past experience and move fast so even if those hosts offer some discounts up front, the learning curve isn’t worth it to me.
Bottom line, there’s not any significant across-the-board pricing advantage between the major clouds. They’re all racing to the bottom with their pricing. Just pick the one that you’re the most comfortable with and has the features that best fit your needs.
Anyway, my pick is AWS.
Here’s where we get into the first strategic decision. My service is going to have a REST API component that clients will use to manage their sites. Clients will need to interact with this API every time they update their site but it’s impossible to predict how often that will be. No matter what, it needs to be quick and respond back to the client fast.
So let’s say I want to host my API web app on a couple of EC2 instances with load balancing. Pretty standard setup.
Ok so with this model we already have a problem: the cost for my web application hosting is $61/mo. That means, I’d need to have 13 pro users and 1,300 free users before this broke even—way above the $0.05 per 100 users Holy Gail. This setup would have to easily support 120k users before it hit that number. I’m not sure two medium instances will be able to do that. And there’s another problem: I’m going to have to manually scale this infrastructure as my service scales: monitor response time, CPU usage, latency. That takes time and attention and more money. There’s a better way to do this.
It’s called Serverless.
So what happens if I build my application logic using Serverless Lambda functions behind API Gateway?
With Lambda I don’t have to worry about a server, I only need to know how much memory an API request is going to take and how long it should run. In my setup, each HTTP request translates to one Lambda invocation. All of my requests are only doing things like DB lookups and responding back to the client (nothing memory/cpu intensive like image resizing, etc) so I feel pretty comfortable using 128MB of memory for each invocation. But how many requests will my users make? Ok here’s some more paper napkin math:
But I also want to use API Gateway so let’s add that in too:
The other benefit with Lambda + API gateway is that it automatically scales to meet demand. If nobody uses it. I pay nothing. If more people use it, I pay accordingly. I don’t need to monitor servers and try to match my EC2 instances to meet need. It all just happens. This is much more sustainable.
One more thing though, Lambda and API Gateway have a free tier. It’s going to be a while before I even need to start paying for them. With these numbers I can scale to 25k users before I pay anything.
⚡️ Web application total cost per 100 users (after 25k users): $0.074
Sigh, databases. It’s impossible to build a web app without them but they’re almost always the bottleneck and a great source of pain and suffering. If you don’t do backups right, optimize your queries and indexes, and set up replication correctly you can find yourself in a world of hurt. If your app is slow, it’s almost always because of your database. Fortunately my service has a pretty simple data model: we’re just tracking users, websites, and what’s in those sites. A fundamental requirement is automated backups and the ability to restore. A simple data model makes No-SQL a good candidate but let’s look at this with a few different scenarios:
So just to start development with any of those databases, I’d be immediately loosing money.
But let’s look at DynamoDB.
Dynamo charges on requests, storage, and backups. Let’s crunch some numbers:
⚡️ Database total costs per 100 users: $0.05
The last part of my service is hosting customer static web files and serving them up over a CDN. This is where things can get really dangerous. What happens if someone hosts a webpage with an embedded video and that webpage goes to the front of HackerNews and gets 200k visits in a single day? I need to be very careful how I structure the free and pro tiers so I don’t get killed with bandwidth and storage. Here’s what I’m thinking:
I’m building a static web host, not a media service. These limits should be more than enough for the average site with HTML, CSS, JS and images.
For the block storage I’ll use S3 and for the CDN I’ll use CloudFront. (I’ll limit the CloudFront CDN to US and EU pricing just to make things simpler.)
Again at this model, I won’t start even going over the free tier until I break 5,000 users.
⚡️ Data storage and transfer costs per 100 users: $1.394
One of the reasons I’ve written this article is that I wanted to show how big of an impact your technology and architecture choices can have on the sustainability of your business. You need to keep costs low when you’re starting out but you also need to keep them low as you scale. If you pick the wrong tech or price things the wrong way, you can find yourself with a hosting bill that you won’t be able to pay. But if you use technologies that are designed for your needs and budget, you can go from small to big while maintaining a healthy profit.
To recap, here’s the ranges of pricing scenarios that I covered in this article:
⚡️ Final hosting costs per 100 users: $1.424/mo.
$3.58/mo
profit.
That looks pretty sustainable to me.
Obviously there’s other ways to make your business profitable than just picking serverless, cheap technologies. You can raise your pricing, increase conversion rates from free, reduce the amount of expensive features you give your free users, etc. But my recommendation is to go cheap when starting out. Build a business that automatically scales with your success and doesn’t punish your wallet for early experiments. Hit me up if you have any questions. Have fun!
🤓 If you want to follow along with me as I build a static web host for designers, sign up for the Wunderbucket beta. Let me know that you came from this article and I'll be sure to put you to the front of the line.