Software as a Service (SaaS): Why Subscription Apps Beat On-Premise for Most Businesses
In 1999, Siebel Systems sold enterprise CRM software on CDs. A company that wanted customer relationship management had to buy licences (typically 50 per user per month. Nobody bought CDs. Within a decade, the on-premise CRM market had collapsed. That is the SaaS disruption pattern in its clearest form.
SaaS (Software as a Service) delivers complete, fully functional applications over the internet through a web browser or mobile app. The provider hosts everything: the hardware, the operating system, the database, the application code, and the updates. The customer subscribes, logs in, and uses the product.
The Economics That Drive SaaS Adoption
The financial argument for SaaS is often framed around cost, but the more precise argument is about cost predictability and time-to-value.
Capital to operational expenditure: On-premise software requires a large upfront licence fee plus hardware. SaaS converts that to a predictable monthly or annual subscription. For a finance department, a known 400,000 capital project with uncertain ongoing maintenance costs.
Time-to-value: A company can sign up for Slack and have 500 employees using it productively in the same week. The equivalent on-premise messaging server would require weeks of IT work before a single message is sent. For most business tools, the SaaS version reaches productivity faster.
Automatic updates: On-premise software requires scheduled maintenance windows, regression testing, and compatibility verification before each upgrade. With SaaS, the provider ships updates continuously. Every customer gets the latest features and security patches without IT involvement.
SaaS vs On-Premise: Total Cost Comparison (per 500 users, 5 years)--------------------------------------------------------------------- On-Premise SaaSLicence cost $750,000 $0 (included)Hardware $150,000 $0Implementation $100,000 $5,000Annual support $75,000/yr $0 (included)Upgrades $50,000 each $0 (automatic)IT staff 1 FTE ($80,000/yr) 0.1 FTE
5-year total: ~$1.5M ~$300,000The numbers vary by software category, but the directional story is consistent across most enterprise software.
Multi-Tenancy: How SaaS Providers Serve Many Customers from One System
The technical innovation that makes SaaS economics work is multi-tenancy. A single instance of the application — one database, one application deployment, one set of servers — serves thousands of customers simultaneously, with each customer’s data isolated from every other customer’s.
In a properly designed multi-tenant SaaS application:
- Customer A cannot see Customer B’s data under any circumstances
- All customers share the same application code version
- A bug fix for one customer is a bug fix for all customers
- Infrastructure costs are spread across all customers, making unit economics work
The alternative is “multi-instance” SaaS, where each customer gets a dedicated deployment. This is sometimes called “single-tenant SaaS.” It offers stronger isolation guarantees and is common in regulated industries, but costs more to operate and typically commands a premium price.
Multi-Tenant vs Single-Tenant SaaS-------------------------------------Multi-Tenant: [Shared App Server] <-- Customer A, B, C all connected [Shared DB] -- tenant ID isolates data per row Cost per customer: LOW
Single-Tenant: [App A] [App B] [App C] -- separate deployments [DB A] [DB B] [DB C] -- separate databases Cost per customer: HIGHER Isolation: STRONGERIntegration: SaaS Does Not Live in Isolation
The single biggest operational challenge with SaaS is that most organisations use dozens of SaaS products, and these products need to share data. A sales team closes a deal in Salesforce — that deal needs to flow into HubSpot for marketing, into NetSuite for finance, and into Jira for product delivery. Getting data to move reliably between SaaS products without manual re-entry is the integration problem.
Three common approaches:
Native integrations: Many SaaS products offer direct integrations with common other products. Salesforce to HubSpot, Slack to Jira. These are maintained by the vendors and require minimal configuration.
iPaaS (Integration Platform as a Service): Tools like Zapier, MuleSoft, or Workato connect SaaS products through a visual workflow builder. A trigger in one system (new deal in Salesforce) causes an action in another (create project in Jira). Good for moderate complexity without custom development.
API integration: Direct integration using each product’s REST or GraphQL API. Maximum flexibility, requires developer time, but handles complex multi-step logic that visual tools cannot.
When On-Premise Still Makes More Sense
SaaS is not universally superior. There are specific scenarios where on-premise or private cloud remains the correct answer.
Regulatory environments with data residency requirements: Some regulations require that data never leaves a specific country or crosses certain network boundaries. If the SaaS provider cannot guarantee data residency to the required standard, on-premise is necessary. This is common in German banking (DSGVO), Chinese data laws, and some government contracts.
Very high data volumes with tight latency requirements: SaaS applications communicate over the internet. If your application processes millions of transactions per second and needs sub-millisecond database response, the network round-trips to a SaaS API introduce unacceptable latency. High-frequency trading, real-time signal processing, and some manufacturing control systems fall in this category.
Highly customised workflows: SaaS products are opinionated. If your business process requires something the product was not designed for, you either work around it, request a feature, or stick with a custom-built on-premise system. For truly niche industries with unique processes, the best SaaS product may cover 70% of needs — and the 30% gap may make the product unusable.
Perpetual licence economics: For very large deployments where the per-seat SaaS cost exceeds what equivalent on-premise perpetual licences would cost amortised over five years, on-premise may win on pure economics. This is increasingly rare but does occur in very large enterprise scenarios.
The practical reality for most businesses is that SaaS handles the vast majority of horizontal tools — email, collaboration, CRM, HR, finance, project management — while on-premise or custom-built systems handle the vertical, industry-specific processes that define competitive differentiation. That hybrid model, using SaaS where it fits and custom solutions where it does not, is where most mature organisations land.