SaaS Mindset: Understanding Software as a Business Model, Not Just Technology

Ask 10 VPs of Engineering to describe SaaS and you’ll probably get 10 different answers – with broad agreement on the easy parts and sharp disagreement on everything else. Everyone agrees that it generally speaking runs in the cloud, hosts in a browser, and updates itself – but fewer will agree on what exactly goes on underneath. To some, it’s a shared multi-tenant system where a single instance serves thousands of simultaneous users. To others, it’s simply enterprise software that happens to host in the cloud rather than on-premises. But despite these differences, both would describe their offering as SaaS. Partly because they’re right – but also because the definition has quietly changed throughout the past 25 years, as the initial rough edges have been smoothed out by competing vendors.

As an emergent property of the development and deployment practices around it, SaaS has a unique history that informs its present definition – and the best way to understand what it is, is to understand where it came from.

The original building blocks of SaaS were known as ASPs or Application Service Providers. They essentially rented out existing applications, running them on their own hardware and providing access to their customers via the internet. ASPs’ economic model, however, usually failed to account for the fundamental difference between applications that run on one’s own hardware versus ones that run elsewhere – and most ASPs went out of business by the early 2000s. Salesforce, the company that would eventually found the modern understanding of SaaS, was founded in March 1999 by Marc Benioff and his cofounders. Unlike most other companies at the time that had preexisting applications they hosted for their customers, Salesforce built a browser-accessible system with a shared, multi-tenant architecture in mind from the beginning. The company’s early marketing campaign, ‘No Software,’ which featured crossed-out software on its ads and taxis, promised that its clients would no longer have to wrestle with software installations, upgrades, and versions. Several key events followed shortly thereafter in 2001, with Concur’s switch to SaaS being one of them – but Gmail’s launch in 2004 and AWS’s founding in 2006 were also critical in enabling the adoption of the SaaS model. What was initially a single company’s offering has since seen its market value grow exponentially, reaching somewhere in the region of $400–500 billion and a yearly growth rate of over 15%.

The defining characteristic of the SaaS architecture is the shift from individual customer deployments to a shared, multi-tenant one. Whereas in ASP-based software, individual customers still had their own, separate instances, in SaaS these are consolidated into a single, shared one. This shift is reflected in the switch from the word ‘customers’ to ‘tenants.’ In many ways, it represents a fundamental departure from prior practices – a SaaS tenant does not own what they use, unlike a client-server database or a colocated server instance, which are still built around the master-slave paradigm. Instead, a tenant shares a SaaS instance in the same way that an apartment complex resident shares a building with their neighbors. The benefits of this approach are considerable – a single deployment of a shared instance update every tenant at once, and telemetry, monitoring and onboarding are much simpler across tenants as they have a common reference point. Meanwhile, the costs scale much closer to actual utilization than to the number of customers, as compared to the traditional enterprise licensing model. The complexity is not gone, however – quite the opposite, in many ways a SaaS instance is considerably more difficult to design than a traditional single-tenant application. But those complexities are necessary to reap the rewards of the paradigm.

The single greatest mistake made by young SaaS companies is trying to build their application first and everything else as an afterthought. In practice, the opposite should be done – a well-designed SaaS application rarely launches successfully without substantial investment in the surrounding subsystems first. This approach may seem unintuitive at first – one would think that the application itself, the product, is more important than the channels through which it is distributed, billed, or monitored. Reality shows the opposite – if the billing integration for a SaaS application fails, then the product, for all its elegance, is unavailable to paying customers and therefore much harder to sell. Likewise, if individual tenants cannot be monitored, scaled, or supported separately, the entire system becomes much more difficult to manage. The subsystems surrounding the application are what make multi-tenancy viable, and therefore form its foundation. This is why thinking about them in terms of enablers is such a useful exercise – a tenant-aware application is much less likely to launch successfully if it lacks the operational infrastructure to serve, monitor, support, and upgrade hundreds or thousands of other tenants.

Multi-tenancy is much broader and more varied than most discussions of it would have you believe. At the highest level, SaaS systems can be divided into 3 broad categories based on the reference architecture described by AWS. These are silo, pool, and bridge – with the latter being a combination of the two. In a silo setup, individual tenants have their own stack, but share certain supporting elements like identity, billing, and operations. In a pooled setup, by contrast, there is a shared infrastructure layer, with individual tenants’ data and application code separated out at the data and request layers. Finally, in a bridged setup, some elements are shared while others are fully separated, with the bridge being the demarcation point between the two. For example, some SaaS applications will have a shared front end but separate data warehouses or application code. In practice, however, pool tends to be the ideal choice in most cases, unless there are specific requirements to justify a silo approach – such as regulatory requirements to keep certain classes of data separated. At the same time, pool is not always the best choice for every possible subsystem. Some elements, such as billing, tend to work better when pooled across all tenants – while others, such as regulatory data mentioned above, benefit from being siloed. The primary determining factor of whether a particular application is SaaS is not which design pattern it uses, but whether the tenants share a common experience, deployment, and operations. Even entirely siloed applications hosted in separate VPCs can qualify as SaaS, if the operational experience is otherwise the same. In much the same way that individual instances of MySQL qualify as SaaS, so too can more traditional applications presented over a web interface.

While SaaS applications are rarely entirely self-contained and can leverage third party services, the key differentiator is that these are abstracted away behind the interface used by the tenant. If tenants interact directly with the supporting infrastructure, API or otherwise, it is no longer SaaS. By this definition, managed services such as those offered by MSPs are not SaaS – even if they offer similar benefits, such as eliminating the need for an enterprise to host and maintain their own infrastructure. Individual customer instances running on the same shared backend tend to blur the lines between SaaS and managed services, however, and are occasionally referred to as private SaaS. In practice, they represent a viable stepping stone for companies looking to transition from a legacy enterprise software business model to SaaS. Even at that, they lack one critical characteristic that is near-universally seen in pure SaaS products – a common instance shared by all customers. That characteristic, in turn, is what enables most of the other benefits, such as a shared customer lifecycle and a common instance that can be deployed once and updated for all customers.

While the characteristics of SaaS software are frequently what people tend to ask about, the most important distinction is actually one that few people bother to consider – the business model. SaaS is, at its core, a business model and not a software design pattern. The metrics used within it often do not have equivalents elsewhere within the enterprise software sphere. Net Retention, the percentage of revenue from existing customers that a business retains, is one such example. It has supplanted many other metrics as the preferred way to evaluate a SaaS business, as it captures the ability of a particular SaaS product to drive growth – and the reason for that is simple: it reflects the ability to get more money from the same customer without having to acquire new ones. In a SaaS business, expansion and retention are critically important – and they tend to be quite difficult to achieve, particularly as the business matures and a significant portion of the addressable market has already been acquired. A healthy SaaS business, in particular one that is performing well, will have a net retention rate of over 100% – for every dollar of ARR, a business retains and grows by at least another dollar per year on average, without having to acquire new customers. Most private B2B SaaS companies have a net retention rate of between 100% and 120% overall, with the strongest performers regularly hitting far above that.

The ability to operate at scale without significant increases in operational costs or complexity, and to continue to deliver value and drive growth even in mature markets is what makes agility such a valuable asset for a SaaS company. It is the reason why SaaS products can offer significantly better lifetime value per customer compared to traditional enterprise software. Not only is an individual customer more valuable, but said value grows with the tenure of that customer. As a product matures and its capabilities expand, an existing customer is more likely to adopt it and expand their spend compared to a new acquisition.

Together, these characteristics form the foundation of a definition based on both business and technology. SaaS is a business model focused on providing a frictionless, service-oriented experience, maximized agility, and operational efficiency as a means of capturing value. Software design patterns, such as multi-tenancy, enable these goals but are subordinate to them – and the details of the implementation dictate how successful a given SaaS offering will be. By focusing on these principles, a business can maximize its ability to capture value from the SaaS economy. The importance of the concepts discussed in this article vary depending on the business and product, but a strong understanding of them is crucial for developing a SaaS product successfully. These characteristics serve as an informal set of requirements that must be met for an offering to be considered SaaS. Teams that understand them can dedicate their resources to actually building the core infrastructure that serves all SaaS tenants.