How to Choose the Right SaaS Architecture for Your Startup?

Solution Architect - 30 March 2020 -
Solution Architect - 30 March 2020 -
Having worked as a solution architect and designed multiple SaaS applications over the years, I could see most startups struggling to choose the right SaaS architecture for their product offering.
In this article, I’ve compiled all my learnings into a cheat sheet to help startup founders looking to build SaaS applications make a pragmatic decision. In fact, these inputs have proven facts and data to back their worth.
Customers are increasingly choosing the ‘pay-as-you-go’ pricing model because of its flexibility. Also, it is more effective than the one-time pricing model. To enable ‘pay-as-you-go’, you need the right architecture to support it. When we say the right architecture, it should allow your startup to track usage of services and offer customers the flexibility of managing infrastructure as per their requirements.
A poorly designed architecture creates limitations in setting the right pricing strategy for the offerings. It impacts the acquisition of new customers. On the other hand, a good architecture helps set the right pricing model and accommodate special architecture-design requirements. The latter includes scalability and customizability. For having a clear idea of the pricing model before setting up SaaS architecture, a startup needs to get answers to these questions-
In a SaaS setup, costs incurred in managing operations impact profitability to a large extent. Operational expenses optimization involved in managing the SaaS model depends on three crucial factors – infrastructure cost, IT administration cost, and licensing cost.
However, the bigger question is- how do you ensure that these costs are well-optimized and priced correctly? In fact, I’ve listed below a few examples to demonstrate the same–
Salesforce Online- Salesforce provides a lead management system for sales and marketing teams for enterprises. The online version uses the cloud to reduce the hassles of hardware and IT procurement. It also charges customers based on the size of sales and marketing teams to stop the payment of one-time high license costs.
SQL Azure- SQL server is the industry leader when it comes to RDBMS. It provides a hosted solution wherein customer needs to pay high license cost, hire a DBA for regulating backup, geographical replication, and disaster recovery (important for databases). But, Azure SQL is a cloud-based system that’s accessible online. There you only pay for storage and IOPS, with the rest is taken care of by Azure (cloud provider).
WordPress – Every enterprise needs a content management system, and WordPress has been at the forefront of this. WordPress provides an online platform with white-labeled solutions, customization, and multiple integrations for their customers. Moreover, it collects customer usage data and charges on the basis of it.
This might a common question popping up in your mind. Let me explain with two different examples-
Example 1- Let’s consider an instance where a startup introduces isolated application VMs (Virtual Machines) for all its customers. In the majority of cases, these boxes will remain under-utilized. With customers paying only for utilization, the startup could end up with huge losses.
Example 2- Consider a second instance where all customers of the startup share the database servers & application servers are paying only for utilization. In addition, this is a fair game for the startup as all of the hardware and automation are being properly utilized. However, a sudden increase in server utilization by one customer can trigger performance issues and unexpected breakdowns for others.
When a startup starts building a SaaS application, it essentially bears the hardware and automation costs. Hence, it’s crucial to pick the right SaaS architecture aligned with your offerings to optimize the above-mentioned costs. Damage control is still possible in the above-mentioned examples but you will definitely lose a big share of time and opportunities.
Type 4 (Doesn’t require data & runtime isolation)
This is the most basic type of SaaS application. In this type, you assume all of your customers to grow uniformly, and to create customer ID accordingly. These customer IDs are added to all of the tables/collection and all customers share the database and application hardware.
Type 3 (Requires data isolation but no runtime isolation)
This is one-step advanced as compared to type 4. In this type, different data stores are put in place for different customers, however, the application is shared by all the customers.
Type 2 (Requires data & runtime isolation on the cloud)
This type involves separate applications and separate data stores for all customers. In this case, the cost of isolation is typically passed on to the customers.
Type 1 (Requires data & runtime isolation, but not on the cloud)
This type is a version of type 2 wherein customer wants data to be stored on their own network and not on the cloud. Herein, the customer still opts for ‘pay as you go’ or a pricing model that’s based on users/features as per on-boarding.
Depending on the type of industry and nature of data, a customer’s requirement for security and shareability varies. A startup can try to understand the needs of multiple customers, and refer to the flowchart given below to select the right SaaS architecture type-
In conclusion, as startups grow, molding existing architectures to accommodate demands from the growing user base becomes difficult. Hence, it’s always good to choose the right SaaS architecture at the start, so that you don’t lose out on business because of rigid architecture.
Leave a Reply