5 Must Haves to Scale your SaaS

Scalability, Scalability, Scalability!! 

When we talk about Scalability, the first things that come to our mind are a large userbase, few million requests per second, huge volumes of data, and so on. At Lockstep, we have scaled multiple SaaS products that serve thousands of B2B customers across dozens of industries and countries and powered by our experienced engineers, collaborating across several teams and departments. Here are 5 other things that need to scale when building a SaaS offering more often than you think. 

#1 Scaling to a large, diverse set of industries and custom asks 

Depending on the type of application, you might be having clients across industries. For example, a CRM or fintech automation can be used by a car manufacturing company, a shoe company, a poultry company or even another software company. All of them will have some differences in their flow. Can your product scale across these different industries? 

Approach 

Giving your implementers and/or users the ability to customize small parts of your application, can go a long way in ensuring stable scalability across different industry practices. For example, allowing implementers and users to create Custom Fields on your forms, creating validation rules or configuring custom actions without the need for code changes. This ensures quick implementation cycles, fewer ad-hoc items for developer teams and more time for product managers to solve problems that matter to all. 

#2 Scaling with changing requirements 

How easily can your product accommodate changes in policies, rules, or priorities? Imagine how every Finance, POS and ERP software in the Indian market needed to adapt when GST came into existence in India. 

Approach 

Honestly, I have not seen a single formula available to tackle this. There are functional aspects of your business processes and technical aspects of how you implement those as features, that decide how resilient you are to policy/rule changes or changes in business priorities. To make this happen, product managers and Engineering teams need to work together to plan features.  

However, in most cases, breaking features into simpler, fundamental processes and building as layers of abstractions does the trick. 

#3 Scaling with business size 

Every product caters to a particular size-segment in the market mainly but being able to scale your process up and down with its customer’s size of business is a superpower that increases the total market and gives customers confidence that they won’t outgrow you. 

Approach 

Similarly, there are two parts of your solution to get right.  

First, functionally see what part of your software flow is essential to everyone, no matter how small or big. Then figure out what added features might be needed on top of those essentials that larger companies can benefit from. For example, in an inventory flow, all your customers will need a Purchase Invoice entry at minimum. A bit larger/ambitious customer will want to create Purchase Orders, GRN, and then invoices. An even more ambitious customer will want a multi-stage approval system for all the orders and invoices.  

More complex businesses wanting granular finance integration may also want to keep Inventory-AP Accrual accounts. Notice how each of these features cater to the same use case and build on the same core system but applicable for only a particular size / type of company. 

Second is the technical aspect of solving it. Once you are clear about the functional layering, plan how to arrange the data structures in your application conforming to the functional design. Once complete, it is as simple as hiding or showing a set of screens or fields based on feature flags that your implementation team can configure. This is key, because there will be times where you may want to create a set of template configurations for different business sizes within your application. 

#4 Scaling with region of use and legislations 

How well does it follow regional preferences and legislation, or how internationally scalable is your product? For example, if your SaaS product is used in Europe, you must comply with GDPR norms, ensuring which is technically challenging. Localizations like currency, unit of measurements, time zones, language support are a few examples to make an application internationally scalable. 

Approach 

This is more straightforward than the other cases. These are features that need to be built to support customers from different regions and/or legislations. For example, simple things like the ability to change currency or fiscal year dates for an accounting system. Regional language support is another common feature. For GDPR compliance, Data-On-Rest Encryption for personally-identifiable-information (PII) might be something you can implement. 

However, it’s important to note that most of these features are fundamental and core to your design. In other words, these typically require much more effort to include later than if you designed your core SaaS by keeping these in mind in the first place. Consider an application that has no support for language translation; from the time that you plan to include language translations, you might end up spending months or even years collecting all the hardcoded strings in your application across hundreds of screens, creating translations for them and testing them in your newly supported languages. 

#5 Scaling with developer team size 

How large can your team size grow and still your codebases be manageable? When you start building a product, you start with a small team of developers. As the product journey continues, many developers come and go, and your team typically keeps growing up to some point. You may realize that the development practices that worked well with your small team may create hindrance in your larger team or you may see code quality degrading, production bugs increasing, and deployments failing often. 

Approach 

There are a lot of standards and different development practices that work well for different team sizes. However, some of the considerations that are harder (if not impossible) to change later are your programming language, primary database, multi-tenancy strategy, ORM, web-framework etc.  

Choosing a philosophy like DRY or Conventions-Over-Configuration may help a small team thrive but can also be useful as you scale to a larger team. If you have your coding practices decided, it will be a matter of creating automated tools (like code-cops and linters) to enforce them when a team grows. 

Using statically typed languages, good well-known conventions, coding styles, modular structure, good unit, and integration tests, DevOps practices all makes your product codebase more friendly to be constantly productive for a small team as well as for a larger team as you grow. 

Blog by: Arpan Mukherjee, Lockstep