In the past decade, the software-as-a-service (SaaS) business model has gained a lot of traction, and for good reason: they’re believed to be more agile than their larger counterparts, and typically have a lower entry barrier than traditional businesses – all of which helps them to be more profitable.
And the growth trend continues: the global SaaS market, valued at around $152 billion in 2022, is expected to grow to $227 billion by 2025. However, starting a SaaS product may not be as straightforward as some people expect. In fact, the way you start your SaaS product can make or break your company.
When building a SaaS business, most companies start with a monolithic type of product, where all customers share the same resources. Multi-related tasks can be handled by monolithic software. They frequently involve numerous tightly coupled functions and are sophisticated applications.
Given their broad application, monolithic tools typically have sizeable code bases. Moreover, the entire platform may need to be compiled and tested to make a simple modification to a single function, which is contrary to the agile methodology that most developers use today.
Other companies will develop the product as small, dedicated environments that will clone for each customer. Since the container world has developed so much lately, this option is the one that will allow you to scale and further develop.
Containers share the machine's operating system core and do not require an operating system to go with each program. Therefore, they are frequently referred to as ‘lightweight’ software.
In this article, I will share the pros and cons of both approaches to building a solid SaaS product to help you decide what is the best approach for your company’s needs.
The monolithic approach
This method of developing a SaaS product requires a significant amount of programming effort in terms of user types and permissions, designing the database to accommodate multiple companies and data, and adding extra security features.
The tricky part comes when your product is gaining some traction and it’s time to scale. The database grows bigger, while customers want their data stored in certain areas for compliance reasons.
When companies develop such a SaaS environment, without knowing it, they start developing an internal product to maintain their infrastructure. Thus, they adopt various tools, develop and manage the scripts, invest time in support and maintenance, etc.
Keep in mind that AWS was such a product for Amazon, in the beginning!
Challenges of a monolithic approach
As mentioned above, as your company expands, the complexity and upkeep of its internal product will increase. That is why, as you scale, greater hardware power will be required. However, hardware cannot be pushed beyond its limits, preventing your business from scaling further.
'For example, I worked for a company that had the biggest hardware usage between 7am and 10am and again from 4pm to 6 pm. Between those intervals the servers did not do too much work. Being a monolith SaaS, there was no feasible way for us to close the servers and reduce costs', says Bogdan Dumitru, VP of Product at Kubeark.
Problems with handling the database
Another challenge inherent to a monolithic approach to building your SaaS product is maintaining your database. Given its size, you will end up with database challenges, such as: data transfer, data management, backup, and others. Also, it will be a headache to delete all the data, if one of your clients decides they want to cancel their subscription.
On top of this, having accurate analytics will also become an issue, as you will not be able to tell exactly how many resources a client is using and what developments are needed.
Predicting your company’s growth pace will also be a challenge since the analytics you obtain will not reflect the real performance data.
Not least, the monolithic approach leaves you more vulnerable in the face of impending cybersecurity threats. In the event of a hack, the perpetrators will gain access easier to sensitive information about your clients. One line of defense is building a multitenant application. However, that will require a lot of development work.
Overall, maintaining a sizeable database running at optimum parameters while you scale can be a costly affair. You will need to hire more experienced workers as your infrastructure expands because few people have the skills necessary to manage massive databases - and those that do are expensive.
In Part 2 of this blog, we discuss the benefits of having a dedicated environment approach. Click here to continue reading the insights.