SaaS (software as a service)

SaaS is thus the most consistent form of cloud software: instead of a product that belongs to you, you use a service that is made available to you.

This model has fundamentally changed the software industry over the past twenty years. In the past, a company bought a licence, installed the software on its own servers and took care of operation, backups and version changes itself. Today SaaS is the norm for most standard tasks: CRM, email, project management, accounting, HR. The question is no longer whether a company uses SaaS, but for which processes SaaS is the right choice and where the limits of the model lie.

How SaaS works

Technically, SaaS is almost always based on multi-tenancy: the provider runs one central installation of its software that many customers share. Each customer only sees its own data, but all run on the same code base. That is the economic core of the model. Because the provider only has to maintain one system, it can roll out updates, security patches and new features for all customers at the same time, without anyone at your end planning an update date. You always work on the current version. You do not need your own IT team for operation.

The downside follows from the same principle: because all customers use the same software, the provider determines the range of functions, the roadmap and the release cycle. Individual adjustments are only possible within the configuration provided. Where the application reaches its limits, open interfaces help: almost every serious SaaS product offers an API through which data can be read and written, and many inform connected systems of events via webhook. In practice, this integration capability often determines the quality of a SaaS product more than the feature list itself.

Pricing models: per seat, usage-based and tiered plans

SaaS is paid for by subscription, but the billing logic differs considerably, and it determines how your costs scale:

• Per seat (per user): the classic. Salesforce, Google Workspace or Personio charge per user and month. Predictable, but costs grow linearly with the team, regardless of how intensively each individual uses the tool.
• Usage-based: you pay for actual consumption. Twilio, for example, charges per SMS sent or per minute of call time. Fair with fluctuating usage, but harder to budget, and costs rise with strong growth.
• Tiered plans: fixed packages with an increasing range of functions, often combined with limits. Shopify tiers its plans in this way and adds transaction fees that depend on the plan chosen.
• Hybrid models: a base fee plus consumption-based components, common with platforms offering API access or AI functions.

For the assessment, the entry price matters less than the cost trajectory over years: a per-seat model that looks cheap with ten users looks different with two hundred. That is exactly why every SaaS decision belongs in a total cost calculation; more on this below.

SaaS, PaaS, IaaS and on-premise: the distinction

SaaS is one of three cloud service models described by the US National Institute of Standards and Technology in its frequently cited definition NIST SP 800-145. The difference lies in how much the provider runs and how much you are responsible for yourself:

The boundaries are fluid. A self-hosted Shopware on a Hetzner server is on-premise software on IaaS; the same Shopware as a managed cloud variant moves towards SaaS. The decisive question is always: who bears responsibility for operation, and how much control do you give up in return?

Well-known SaaS examples

Salesforce is the defining example of the category. The company started in 1999 with a CRM in the browser and the provocative slogan "No Software", aimed at the installed business software that was usual at the time. Today the per-user subscription model that Salesforce popularised is the industry standard.

Google Workspace shows SaaS in everyday life: email, calendar, documents and video conferencing as one subscription per user, without a mail server having to be maintained anywhere. Shopify transfers the principle to e-commerce: the complete online shop runs as a hosted service, the platform takes care of updates and scaling, and you pay a tiered plan plus fees. This contrasts with self-hosted shop systems, where operation and customisability are in your own hands. And Personio is an example of the fact that SaaS has long ceased to be a US phenomenon: the Munich-based HR platform charges per employee and has become widely established among German mid-sized companies.

Build vs buy: buy SaaS or develop your own?

For companies, SaaS is rarely an either-or question but a portfolio question. The useful rule of thumb: processes that do not set you apart from the competition, you buy as SaaS. Accounting, email, HR administration, standard CRM: here the offering is mature, the price fair and any in-house development wasted budget. Processes that carry your competitive advantage, such as a product configurator, special pricing logic or a customer portal, by definition do not come off the shelf. That is where custom software pays off.

The cost side of this decision is often calculated wrongly. SaaS starts cheaply and then grows: with every licence, every additional module, every integration tool that closes the gaps between the subscriptions. In-house development starts expensively and then flattens out, but never disappears, because maintenance is a permanent cost. The only meaningful measure is therefore the total cost of ownership over three to five years, with realistic user and feature growth on the SaaS side and an honest maintenance calculation on the build side. The point at which the two curves intersect is the real decision point, not the price in the first month.

Vendor lock-in and the exit path

The most important strategic objection to SaaS is dependency. Your data is with the provider, your processes adapt to its product, your team learns its interface. The longer you use it, the more expensive it becomes to switch. This pattern is called vendor lock-in, and it is not a theoretical risk: price increases after the introductory phase, discontinued features or the end-of-life of a product hit you all the harder the more deeply the tool is embedded in your processes.

The answer to this is not to forgo SaaS but a planned exit path, which you check before introduction, not only when a conflict arises. The most important questions:

• Data export: can you get all your data out in an open, machine-readable format, including attachments, history and metadata? Or only a CSV file with the master data?
• API completeness: does the API cover everything the interface can do? A complete API is the best exit insurance because it enables automated migration.
• Contract term and notice periods: annual contracts with automatic renewal are usual; what matters is what happens to your data after cancellation and how long you still have access.
• Data protection and hosting location: for personal data you need a data processing agreement, and the hosting location helps determine which additional legal questions you take on.
• Closeness to standards: does the product use open standards and common formats, or proprietary structures that no other system understands?

Anyone who clarifies these points before signing can use SaaS with a clear conscience. Anyone who ignores them will notice, the first time they want to switch, what the low monthly price really cost.

Advantages and limits of SaaS

The strengths of the model are real and explain its triumph. SaaS is ready for use immediately, instead of after an implementation project lasting months. Entry costs are low because there are no servers, licences or installation projects. The provider takes care of security, availability and updates, and usually more professionally than the internal IT of a mid-sized company could manage for a single tool. And the product evolves continuously without you having to plan upgrade projects.

The limits are just as real. You are restricted to the functions the provider offers; special requests remain wishes or are solved via workarounds and additional tools that bring their own costs and sources of error. The running costs never end and rise with team size and usage. Without an internet connection, little works. Your data is outside the company, which raises data protection and compliance questions. And for business-critical core processes, an outage or a doubling of prices at the provider is a risk that you cannot control yourself. SaaS is therefore the right choice for everything that is standard and the wrong one for what sets you apart.

Frequently asked questions about SaaS

What is the difference between SaaS and the cloud?
Cloud is the umbrella term for IT resources provided over the internet. SaaS is one of three levels within it: the ready-made application. Below it are PaaS (a platform for your own applications) and IaaS (raw infrastructure such as servers and storage). Every SaaS product runs in the cloud, but not every cloud offering is SaaS.

Can SaaS be used in compliance with data protection law?
Yes, under certain conditions. As soon as personal data is processed, you need a data processing agreement with the provider, and you have to check where the data is hosted. Providers with EU hosting and clear contract documents simplify this considerably. Responsibility for lawful processing nevertheless remains with you as the controller.

Is SaaS more expensive than your own software in the long term?
Not across the board. In the first year, SaaS is almost always cheaper. Over five years the picture can reverse, because subscription costs grow with users, modules and integrations, while custom software mainly costs maintenance after the expensive initial development. What matters is the TCO calculation over the life cycle, not the monthly price.

Can I adapt a SaaS product to my processes?
Only within what the provider allows: configuration, custom fields, sometimes low-code extensions and APIs. Real changes to the software are ruled out because all customers share the same installation. If your process has to adapt to the tool rather than the other way round, and this process sets you apart from the competition, that is a signal for custom development.

What happens to my data when I cancel?
The contract governs this, and that is exactly why you should read it before introduction. Reputable providers offer an export period after the end of the contract and then delete the data verifiably. Check in advance in which format you can export and whether the export is complete. A provider without a usable export is a provider you should avoid.