September 18, 2019 • 6 min read
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:
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).
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:
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:
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.
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:
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.
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:
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.Back to blog list