Synergy or risk? What investors need to know about application scalability

Any technology-focused investment strategy must consider and address scalability. But technical teams and private equity investors may have different definitions of “scalable,” making it difficult to understand how much growth the application can support without additional investment.

The good news? You don’t have to be highly technical to understand the important components of scalability and how it can affect your growth strategy – you just have to ask the right questions.

What is application scalability?

When an application is scalable, it’s configured to function when there’s an uptick in traffic, volume or the size of each request. The technology anticipates and supports increased demand – instead of reactively addressing it.

It starts with your strategy

Before you can estimate the level of scalability required, you must have a clear investment strategy. With defined growth targets in mind, work with your technical advisors to define:

  • How many clients and users do we expect to have in one, three and five years?
  • What information needs to be stored, and by what factor will storage needs grow as we add users?
  • What are the system processing requirements, and how will additional users affect complexity?

Four key components

When acquiring an existing application, it’s important to understand the scalability strategy across four fronts:

  • Architecture. Is the app architected appropriately to support new release deployment? The recommended approach depends upon how the app is updated and deployed.

    Monolithic architecture is a self-contained codebase that includes all components required to execute the code and run the software. It can work well when the application is updated and deployed on a regular schedule.

    A microservices framework leverages multiple lightweight service apps that are coupled together. Each can be developed, maintained and updated separately. When architected well, this framework can provide meaningful support to overall application growth.  
  • Infrastructure. Is the infrastructure designed to scale vertically, horizontally or both? Whether cloud-based or on-premise, infrastructure can generally scale two ways:

    Vertical scaling, or scaling up, increases the processing power of the server by adding more CPUs, storage or RAM. In the cloud, the process is seamless to end users. But in an on-premise scenario, you may need to take the server offline to install the additional capacity, and you’ll be limited by the server’s total capacity.

    Horizontal scaling, or scaling out, adds more servers or nodes (or leverages distributed services that let you scale different parts of the architecture independently). Theoretically, you can scale infinitely – but for each new service, you’ll be adding additional overhead.
  • Data. How is data stored? Most applications today must store data, and the storage method can impact the user experience.

    In a traditional, relational database, data is stored in a structured format: rows of data and linked tables, typically used to support mature databases and rigid data structures and schemes. To modify the structure (add tables or columns or change the code to support new data), you must take the application offline.

    NoSQL databases such as MongoDB store data in documents instead of tables. This approach is used when data doesn’t conform to a relational schema or when the schema is changing frequently, and development must happen quickly. The benefit of noSQL is that it can support large volumes of data (including unstructured data). You can add new data more easily – without modifying code or taking the application offline.
  • Processing. What strategies are used to reduce processing time? There are a number of ways to reduce processing time, including combining or removing steps in the process. Other strategies focus on optimizing processing efficiency to reduce system load. For example:

    If the application requires significant user interaction processing, you should keep that work as close to the client as possible. One way to accomplish this would be to place processing into the scripting engine that loads into the browser.

    You can also leverage asynchronous processing, which takes advantage of the multiprocessing capabilities of the hardware and application operating system, allowing the app to start a process and check the results later.

Understand before you invest

One mid-market EdTech company illustrates how scalability can impact investment strategy. The company’s aging software utilized a monolithic architecture, installed on-premise. The tech team had already begun enabling a SaaS version of the app as part of their growth strategy and assured their investor that it could scale to support the aggressive growth strategy of the investment thesis.

Our review revealed a disconnect. Luckily in this case, the app was in early stages of development, and the challenges discovered during tech diligence were addressable. The acquisition moved forward, with optimization strategies in place for scaling, architecture and processing. The new approach allows the company to “pay as they grow,” adding servers or cloud support as higher traffic and volume thresholds are met. Had these items not been addressed at this early stage, immediately post-acquisition, the company would have encountered scaling issues that could have been costly to address at later stages.

This example reminds us that scalability isn’t just a concern for the technical team. It affects client experience, revenue and earnings, making it an essential consideration in any tech investment strategy.

About the author

Mike Bestvina, managing director at Crosslake, has more than 15 years of experience as a technology advisor and founder, with extensive experience in technical due diligence for private equity investors. His experience equips him to provide the kind of practical advice that investors need in order to understand how scalability may enable or hinder their investment strategy.