9 ways to ensure your SaaS is grown-up and investor-ready

A lot of Software-as-a-Service startups are built by two people, one with the idea and the business plan, and one with the skills to write the code for it. There comes a time in that journey when they've proved the idea has legs, they've built a Minimum Viable Product (or MVP) that they are a little embarrassed about (as conventional wisdom says they should be), they have some amount of customers that are proving there's market interest for it and need funding to be able to grow further. Sound familiar?

Before you go starting to pitch the idea to investors, there are a number of things you should have in place to ensure the business is truly ready for the growth you're about to experience, and this will help investors feel confidence in your answers when you give them.

1. Backups

You should take regular backups, at a considered frequency. For some people this could be daily, for others it would need to be much more frequent. Most importantly though you should have a plan in place for how to use these backups to restore all or part of your SaaS platform if something went wrong. This doesn't have to be a "we can be back up and running in 10 minutes", but a timescale that you can tolerate being down for. Finally, you should have a regular practice of ensuring the backups are valid, restoring them to some test environment and making sure the amount of data present in at least key stores is within a tolerance of your current amount of production data.

2. Monitoring

There's nothing worse than finding out about your site being down than having your customers calling/emailing you, outraged that the service is interrupted. So obviously you should have regular checks in place that ensure service is available, and alerting one or both of you if it isn't. At a more fine grained level, while ensuring the service is available, adding a capacity check with an alert level would be worth it's weight in gold. When space runs out, it can cause all manner of seemingly unrelated problems, so better to find out up-front.

3. Cloud-native approach to hosting

A lot of technical co-founders may start with a simple virtual server, maybe running somewhere in the cloud. However, that doesn't make it cloud-native. Maybe the software to run your platform was manually installed by them (meaning it may not be repeatable in a total-outage situation as mentioned above). Maybe it's designed in such a way that if your traffic increases your only option is to get a bigger server. The problem with that appropach is that there is a limit or at least a cost implication as servers get larger and larger. And you may reach a point where a larger server simply isn't feasible. So it's better ensuring from the start that your platform is installed in an automated, repeatable way to one or more virtual servers, but designed in a way where you can "horizontally scale" by increasing the number of those servers, not the size of one of them. A good way of achieving this is to use a Platform-as-a-Service, which the hosting provider takes care of most of the details of running your SaaS system and scaling it as necessary. A couple of good choices are Heroku.com and Fly.io, but others are available.

4. Log storage

Following on from the cloud native approach (using a PaaS for hosting often has a scrolling window of log availability) and the monitoring for capacity, most servers will configure a relatively small amount of storage for log files. In a normal world this is fine, but part of the growing up of a SaaS platform is preparing for the abnorml world, where something goes wrong and clues on where to look are far and few between. Having a history of log entries going back a week or more, can be like gold dust in figuring out the root cause of any problems. There are various sites available that offer this as a service, for example LogTail.

5. Audits

Depending on how verbose your logs are and how complex your system is, tracking down a problem can result in tens or hundreds of thousands of log lines. If every change to your data is kept in an audit trail, it means you can find the appropriate audit record where something changed that shouldn't have, look at when that audit record was created, and immediately scroll right to the correct place in your log storage system. Obviously the choice of system for doing this varies greatly between programming languages and programming frameworks, so we won't make any specific recommendation - but we would advise that it happens at a very low level. You don't want to have to intentionally create an audit record on every change, because it's pretty much guaranteed, the time you miss out writing that line will be the one place you need it.

6. Masquerading

Log storage and audits are great for "what happened back then", but what happens in the here and now, when a user of your site contacts you and says "Hey, when I do X I get this weird thing happening...". Well, your step 1 is obviously to login to your platform yourself and try to repeat it, but this can be due to a complex set of data stored across multiple places, so maybe for you it works fine. So a really nice step 2 is to be able to "become that user" temporarily on your platform, commonly refered to as masquerading or using "sudo". This enables you to see what they are seeing when you try the same action. You can then increase logging levels or watch for audits, while triggering the issue yourself at-will.

7. Automated tests ("continuously" running)

When you're building the MVP of your product, often time automated tests are skipped. The reason can be that it feels slower to write with tests (effectively building a huge safety net at the same time as you build the project), or that this is simply a planned v1 and will be rewritten as v2 using the benefits of hindsight, as Fred Brooks stated in his first edition of the Mythical Man Month. But as you move past MVP and in to your proper version, it's best practice to at least backfill automated tests to exercise your system. Then as you go forward, where possible write tests. There is a balance to be struck between enough tests and a huge slow test sutie, as well as how deep you test - functionality only or all internals. But it's key that you have some. You can only move fast if you have confidence you aren't accidentally breaking something else. What's also important is that you actually run the tests on every change, otherwise how will you have confidence you catch it before the release. That can be done easily with systems like GitHub Actions or CircleCI.

8. Staging environment

So you have some history of your operation with logs and audits, you have some view of current operation with automated tests and the ability to pretend to be one of users. However, when you are building new functionality, throwing out on the internet to your unsuspecting customerbase can be a time of madness as things break where they didn't on local development machines. So, you should aim very early to build an identical but smaller version of your production system, so that changes can be tested there before promoting to production. A really great practice is to consider this part of your "day zero" setup (i.e. before your first day building the thing) - setup automated tests and continuously running them, hosting for your production site, a staging environment, etc. Get all of that built before you start to write your MVP. It's not always possible or for business reasons wise, but at least consider it.

9. Work from anywhere

The final advice to founders of small companies building SaaS platforms is that unless you want to be constantly chained to your desk, assuming something will go wrong, at the worst possible time, make it as easy to jump on from everywhere as you can. For example, my personal setup involves having all my authentication details in 1Password, our source code available in GitHub and a setup using GitPod available to give me a development environment in a web browser in a single click on anyone's machine. I can jump on a friend or family member's computer, open an Incognito tab in their browser and have my full development environment configured and all my code available in about a minute. I ended up using this on my last holiday, sitting by a pool in Mexico fixing an issue using my iPad with an external keyboard.

Think about what's right for you

All of the above are really part of growing up, but you have to weigh up the time spent integrating those items, against the time that could be spent building your product. Only you will know where the balance lies, only you will know your funding journey position, but they can all help technical co-founders to know they're ready to be questioned by more technical investors on the safety nets you have in place.