Before, software used to be purchased as licenses whereas nowadays subscriptions are the standard. That has brought along convenience for the buyer but a lot of work for the builder – especially in hosting and managing these subscription-based SaaS applications and platforms. Whereas SaaS buyers are able to focus on their core business (thanks to the purchase), SaaS builders face quite opposite situations. The extensive amount of knowledge and time it takes to host and manage SaaS as a service provider has been a topic of the past ten years among developers. And that’s our topic today. In the following, I will share my top learnings from leading the development of a SaaS platform called Aito.ai.

Nowadays hosting and managing means the whole knowledge, skills and experience of how to set the environment up, how to set monitoring there, who is in charge of these tasks, how to make it scalable, how to deal with sudden peaks in traffic, and so on. Hosting and managing is, above all, the experience of utilizing other platforms (e.g. we use AWS, Google Cloud, Azure) to make an optimal setup for hosting and managing your SaaS. That’s also the case with Aito, our predictive database for developers who look to expand their stack of single-purpose tools (e.g. Elastic, Redis, any SQL-database) with a multifunction ML toolset.

In this blog post, I’ll be looking SaaS not as a business model nor as a way to think of software but as a convenience factor for the buyers and builders, i.e. the customers and the developers. Based on my fail and learn experiences in (developing,) hosting and managing the Aito SaaS platform, these are the five key takeaways I’d like to share with you:

1. Managing security and isolation

Hosting a database means that we are responsible for our customers’ data. Regulations like GDPR are of course very topical and demanding – but our customers are even more demanding. That’s where the pressure comes from. Ensuring security and isolation for their (often extremely) sensitive data is the first step we need to take. And to take it, security must be seen as a three-level concept of which all parts must be well covered (note: these three levels apply for SaaS platforms, not certainly for end-user facing SaaS applications).

Ensuring security and isolation for their (often extremely) sensitive data is the first step we need to take.

First, there is infrastructure security, i.e. how well have we set boundaries between different components in the infra so that they don’t access too much yet not too little information. Second, application-security means that applications we host must be secure when deployed and maintained (for example, we use a Node web API so we must make sure it’s safe). Third, there is database-security, in which we must make sure that when our customer puts their data into Aito, they need to trust that no other customers can access the data accidentally. In other words, the data has to be well isolated (think of it as a warehouse where customers have walls between each other).

Covering these three is difficult, and from what I’ve learnt, I recommend the following:

• If your team doesn’t have experience in security issues, hire a consultant or get external help. If you fail in security, you might steer the whole company towards its death.
• Organize security training within the team by trying to hack your own system. It really helps with finding the weak spots and includes the whole team to think security.
• Read the Owasp top 10 vulnerabilities and make sure you cover all of those (web app-level security – which is enough if you run your application on Heroku or similar service that handles server- and infrastructure-level security and isolation)
• Think in layers. The application is constructed from multiple layers, and securing just one is not enough. You should be paranoid when securing every single part of your architecture.

2. Scaling for uncontrollable end-user behaviour

Our team’s background, before founding Aito.ai, was from developing single-purpose applications. Back then, we were often hit by sudden peaks in traffic of our users, something we were not able to see (you never know when someone links you on the front page of Reddit). Now, with Aito, we struggle with even worse blindness: we have no chance of seeing when our customers’ application gets traffic from their users. This asks flexibility from our scalability.

Usually, SaaS platforms push the responsibility of scaling for their customers to handle. That’s pretty simple for the service provider but might irritate the customer when they need to think about which is the right plan for them (remember: they neither have a clue when someone links them on the front page of Reddit). The other approach for service providers is to carry the responsibility of scaling for the uncontrollable end-user behaviour themselves. We chose to do that in order to guarantee that our customers don’t need to think of anything extra. However, scaling our infrastructure and servers automatically based on our customers’ users’ behaviour is pretty damn hard.

It’s possible though, but this is what I recommend from the bottom of my heart and brains:

• As a developer to a developer: try to push the responsibility of scaling to your customers (that makes them actively think about their user behaviour and they can see a clear cause and effect relationship between it and the server costs)
• If you decide to handle the scaling, focus on servers: they don’t scale as light as other parts of the usual SaaS (platform) infrastructure between the customer and the database
• Don’t scale your infrastructure and servers just in case – or why would you produce festival facilities for 10,000 people if you expect 1,000.
• Accept uncertainty: you cannot control your customers’ customers’ behaviour. Just learn to live with it: what felt surprising last week is the new normal next week.

3. Manage expectations internally and externally

Often times, I have faced unrealistic hopes from customers (and sometimes from our team) that our SaaS platform would just scale. Let’s be clear here: SaaS does not just scale – it is built larger, requiring larger infrastructure and larger servers (and a larger team). Internally, people pretty fast learn the laws of subordination, but externally, the mindset is hard to turn from idealistic into realistic.

SaaS doesn’t just scale. It is built larger, requiring larger infrastructure and larger servers.

Exactly that idealistic mindset is what we are fighting against as developers. And it’s totally natural: having used many SaaS products myself (for example AWS at work, Netflix at home, etc.), the minimum expectation is that it can handle my scaling needs. It’s then up to you as a developer to make this process as easy as possible. Fully automatic may be the gold standard, but can be frustrating if it does not work as expected. Handing some of the tools and responsibility to a customer might actually lead to better results.

This advice holds as well internally as externally – and it’s all about communicating things transparently:

• Don’t hide stuff like server limits on your term sheet – no one reads them and that might cause some unpleasant surprises later on
• Be as transparent towards your customers as you can and explain the different plans as clearly as you can
• Let marketing make idealistic promises but remember to be totally honest in onboarding meetings and demos (at the latest)

4. Tying technical solution to the business model

In the end, everything comes down to profitably. That requires fully understanding the cost structure of hosting and managing software – and that information, my fellow developers, cannot be hidden from the business managers either. Profit margin is oftentimes seen only as a business problem but you need technical expertise to know where to cut costs, or where to add them when needed.

In the end, everything comes down to profitably.

There are two kinds of costs in hosting and managing a SaaS platform. First, there is the infrastructure cost with zero customers – the static cost, like rent for restaurants. Second, there is the customer traffic cost – the variable costs, like food ingredients for restaurants. Your pricing should follow the variable cost which shows as higher-priced plans (if you outsourced the scaling for your customers) or as fixed-priced activities (if you wanted to keep the scalability on your table).

Without going further into pricing, the main point here is to get everyone on the same line in what comes to the cost structure of a SaaS application or platform:

• Communicate internally between developers and business managers – wherever there is a price tag, should also be interest from both sides
• Think in scenarios: the expected amount of customers, needed infrastructure for them, estimated peaks in customer traffic, desired service level,... (topical only if you aim for the automated scalability and don’t push the responsibility of scaling to customers)
• Build for a realistic vision: it makes no sense to assume that you’re gonna have 100 times more paying customers next year and scale your product for them already now

For now, these are my reflections for the past years of building Aito.ai. We are currently looking for a Lead Developer to join the team. If you’d be curious to join our team, just ping us here.