Day 7

If you’re never built a SaaS product before all the server-side stuff might seem overwhelming. How many servers do you need? Magnificent monolith or microservices? VPS, app engines, end point computing, dedicated machines? Do you need a CDN? SQL, noSQL, distributed or not, failover, multi-master or RDS? So many decisions! And if you get it wrong it’s going to cost you.

Thankfully, we’ve built SaaS products before which means we’ve got a rough idea of the kind of problems we’re likely to encounter at different levels of usage.

Our guiding principles:

Don’t overspend

The cloud is great in many ways but the virtual machines are underpowered and expensive. Cloud servers make perfect sense when you don’t want to do sysadmin work or when your load is so unpredictable you need to dynamically spin up additional servers. Neither applies for us. A single $100/month dedicated machine gets you 16 cores, 128GB ECC ram, and 8TB of enterprise NVMe SSD storage. That’s a lot of horsepower!

A single server like that can support more simultaneous users than we’re ever going to realistically have. We could probably get a server that’s one third as powerful and not notice the difference. We won’t need to heavily optimize our server code and we won’t have to worry about communication between microservices. A monolith is simple and that eliminates entire classes of bugs, so that’s what we’re going for.

Boring tech is better

We’ll use Debian stable. We don’t mind that all packages are 9 months behind other distributions. We don’t need the latest point release of bash or Python. We want stable packages and regular security updates. That’s what Debian offers.

Django + MySQL is will be the core of our backend stack. Because our SaaS app will be group based (meaning: no shared data between groups) scaling and caching will be very easy. Servers like twitter are complex because every action potentially affects any of the other billion users in the system. But when you make a service where all user groups are independent you don’t get this explosion in complexity. If we suddenly end up with millions of users (yea, right!) and there is no faster server available (vertical scaling) we can still scale horizontally if necessary. It’s just a matter of buying a bunch of servers and evenly dividing our users between them.

We have used Python/Django for years so that’s what we’re going with. We could have picked golang or any other web stack. It doesn’t matter that much.

We don’t need a cache server, a message queue, or any other services at this point.

We should get 99.99% uptime with this server architecture, simply because there is so little that can break. Provided we don’t do anything dumb :). All downtime is bad, of course, but there are diminishing returns at some point. I think 1 minute of downtime per week is acceptable.

Security Paranoia

We’ll cover this in depth in future posts. Firewall, sshd policies, full disk encryption, and intrusion monitoring are core parts. The mantra is: layers of defense. If system files get changed, we want to know about it. If a program listens to an usual port, we want to know.

We’ll do backups with rdiff-backup (local + remote). We can use it to diff what changed on a server, which means it also functions as an audit tool. What makes rdiff-backup so cool is that it computes reverse diffs, as opposed to forward diffs. This means the latest backup set consists of plain files that can easily be verified to be correct. In addition there is some compressed archival that allows you to go back in time for individual files/directories. You never have to worry about the archival system getting corrupted.

For full disk encryption we’re going to need to employ some tricks. We want to encrypt everything, including the OS. For a remote headless server that requires some ingenuity. More about this later.

Mailgun

Mailgun is what we know so that’s what we’ll use for our planning IDE Thymer. Mailgun has always had reliability issues though and deliverability is mediocre, even when using a dedicated IP address. We can always switch transactional email providers at some later point, so it’s not something for us to worry about now. It would just be a distraction.

Cloudflare

Our app server(s) will be in Europe (because of GDPR), but most of our users will be in the VS. That’s not great from a latency point of view. It takes a couple of round trips to establish an SSL connection and if you have to cross an ocean that will make your site feel sluggish.

Cloudflare has many end points globally, and we want our app to load fast. We’ll move all static content to Cloudflare and we’ll make sure to design our app so it can load as much in parallel as possible. Cloudflare also provides us with free DDoS protection and their DNS service is great. One day Cloudflare will start charging startups like ours and we’ll gladly pay. For now, the free plan suits us just fine.

We’re bootstrapping and we’re running our startup on a shoestring budget. Everything on this list is free, except for the server(s) and those are dirt cheap. It’s almost comical how easy and cheap running online services has become. Most of the hip new tech we just don’t need. Our app will be client heavy and the server will be little more than a REST API and billing logic.

Now that we know what we’re going to build, we need a way to reach our initial target audience and find some first “fans” who are willing to try the product.

First we need to determine the target audience. Our app is going to be a very horizontal product, which can make it easier to grow (lots of potential users) but harder to start (it’s very general and we need to know how to reach the very first people to get started). Step one is to think of people who could be our initial fans.

As we wrote about here, we picked something we would use ourselves on purpose, so we know the problem and we can try to reach people like us. Let’s say we look for “busy people who create todo.txt files”. Makers/creatives/startups would fall in that category and are most like us, so easiest to find. Another niche category we can probably find online is people writing about things like productivity, GTD, journaling and so on.

We’ll start creating a list of places to find the audience. Some places we can look are:

Twitter
Subreddits
Forums
Discords
YouTube channels
ProductHunt

We can use good ol’ Google, Twitter search and tools like https://thehiveindex.com to find relevant pages. Once we know where to look, we can do a few things to get the word out:

Be helpful and answer questions people have to get followers. This is easy and fun, but slow.
Directly post what we’re working on and ask feedback (on some places this is actively encouraged, others you have to be careful not to come across as spammy).
Search for messages where people talk about the problem or related products in the space, and reply to ask a question, or if they would be interested in our idea (examples are Twitter threads, DMs on Reddit/Forums, etc.)

Especially the last two can feel awkward because it’s a cold outreach of sorts, and they have the biggest chance of resulting in negative reactions (rejection!), or no reaction at all. That’s all just part of the journey though, at some point you need to tell people you exist. Just a random example, look at how a tiny app called WhatsApp posted like this in 2009: https://www.flyertalk.com/forum/travel-technology/952359-thoughts-about-my-free-iphone-app-whatsapp.html

And of course in many cases feedback will also be very positive and people actually like to discover new cool things.

While finding all those users, we also need to tell them what we’re building and point somewhere to our product. For this we need to create a proper landing page. To get people excited about the product, we want the landing page to do a few things:

Explain what we’re building
Show a little demo video or nice screenshot (we’d let people demo the app if possible, but we don’t have an app yet)
Offer something like early access, a private beta or even accept pre-sales. Ask for a way to contact them so we can email them when we launch.

Sometimes a landing page can just be some text explaining what you’re doing. In case of our app, which is in a busy space, it’s probably necessary to showcase a bit of the app itself (like a compelling demo, to show how it sets itself apart from all the other products). To do this, we need to do a bit of prototyping over the coming days, and create a pre-MVP. We don’t need something people can use yet, but at least some sort of (design) mockup for a “screenshot” or video, to show the vision behind the idea.

In parallel, we’ll continue building everything in public and share our startup lessons. We would do this anyway of course as that’s the point of the 80daystartup, but there will also be some overlap with the target audience for the app, so this too might result in more users for our launch list.

We’ll then need to keep building to create the first minimum viable version of the product (focusing on the core features), while we keep posting, replying and doing “mini launches” up to the official launch day itself.

All of this is a very manual process at the beginning. The aim is to find ways to grow faster organically once we have some first initial fans.

Day 7

A no-nonsense server architecture for group based SaaS

Don’t overspend

Boring tech is better

Security Paranoia

Mailgun

Cloudflare

Initial marketing plan

← Previous day (day 6) • Next day (day 8) →

Read more