What is SaaS?
SaaS means Software as a Service. You subscribe to software that somebody else runs, instead of buying a licence and installing it on machines you are responsible for.
The browser is not the defining trait, even though it is the visible one. Plenty of SaaS products have desktop and mobile clients, and plenty of self-hosted software runs in a browser. What actually distinguishes SaaS is the division of responsibility. The vendor operates the servers, applies updates, takes backups, patches vulnerabilities and commits to availability. You remain responsible for your data, your processes, your users and their permissions.
Seen that way, the subscription is not a payment plan. It is the price of transferring a set of operational obligations to somebody whose full-time job is to carry them. That is usually a good trade for a company whose business is not running servers. The part worth examining is what comes back the other way.
Why SaaS matters
- Operational responsibility moves. Nobody on your side has to plan a version upgrade, monitor disk space or apply a security patch at ten at night. For a company without a systems team, this is the whole argument.
- Cost becomes predictable and immediate. A subscription replaces a capital purchase, which changes how the decision is approved and shortens the time from decision to use.
- Time to value collapses. Starting takes an afternoon rather than a project, which makes it reasonable to test a tool properly before committing to it.
- You inherit changes you did not choose. The counterpart, and the one that is rarely written on the pricing page. The vendor decides when a feature changes, when an interface is redesigned and when an old behaviour is removed. Your team absorbs that on the vendor's schedule.
- Cost accumulates quietly. Per-seat pricing that looks trivial at ten users behaves differently at eighty, and a company rarely revisits a subscription it approved three years earlier. The five-year total is the number that matters and almost nobody calculates it.
For a Belgian company there is now a concrete test of that trade. Structured e-invoicing has been mandatory for domestic business-to-business transactions since 1 January 2026, and whether a subscription tool handles both sending and receiving properly is a question of compliance rather than convenience. It is also a good illustration of the model: when the obligation arrived, SaaS users generally received the capability, while self-hosted users had to plan an upgrade.
How it works
Four mechanisms sit behind almost every SaaS product.
Multi-tenancy. One running application serves many customers, with data separated by design rather than by having a copy per client. This is what makes the economics work, and it is also why you cannot request a version that stays behind while others move forward.
Continuous deployment. Updates arrive when the vendor releases them, often weekly, sometimes daily. There is no upgrade project, and there is also no choice about the timing.
Metered subscription. Billing follows seats, usage, volume or some combination. The pricing dimension chosen tells you where cost will grow as you succeed, and it deserves reading more carefully than the headline price.
Service level commitment. An SLA states the availability the vendor commits to and what happens when it is missed. Read what the remedy actually is: a credit against next month's fee is common, and it does not compensate a day of stopped operations. The SLA describes the vendor's exposure, not yours.
Implementation
Two very different situations hide behind the same word, so the checklist splits.
If you are buying SaaS, four questions decide more than the demonstration does.
- How do you get your data out? Not whether an export exists, but whether it includes history and relationships, and whether you can run it yourself today. Test it during the trial.
- What grows the bill? Seats, records, storage, calls. Model the cost at three times your current size, since that is the scenario where the tool succeeded.
- What does the SLA actually give you? A service credit is not compensation for downtime. Match the commitment against what a day of unavailability would really cost you.
- Is there an API, and is it included? This decides whether the tool can be connected to what you already run, and whether leaving later is a project or an ordeal.
If you are building SaaS from an internal tool, the honest warning is that the working application is the smaller half.
- Multi-tenancy is a rebuild, not a setting. Separating data, permissions and configuration per customer touches the data model, and retrofitting it costs far more than designing for it.
- Billing, trials, and dunning are a product of their own. Subscriptions, proration, failed payments and cancellations are unglamorous and unavoidable.
- Support becomes a function. An internal tool has users you know by name. A product has customers with expectations, response times and a channel somebody must staff.
- Uptime becomes a promise. Once you sell an SLA, you need monitoring, on-call and a plan for the night your database fills up.
- Validate demand before building the platform. The most common failure is a technically excellent product for which three companies were willing to pay, discovered after the multi-tenant rebuild rather than before.
Related technologies and tools
- Multi-tenancy: the architecture that lets one application instance serve many customers with isolated data, and the main technical difference between an internal tool and a product.
- API: the interface that decides whether the tool integrates with your other systems, and what you can take with you when you leave.
- Vendor lock-in: the accumulated cost of leaving, driven by data portability, integration depth and how much of your process now lives in someone else's product.
- SLA: the availability commitment and its remedy, which is usually smaller than buyers assume.
- Subscription billing platforms: the services that handle plans, proration, failed payments and invoicing, which is work you do not want to write yourself.
Conclusion
SaaS is a transfer of operational responsibility, priced monthly. For most companies that is a good exchange, and the model won for solid reasons rather than fashionable ones. The two things worth watching are the ones nobody puts on a pricing page: the total across five years, which per-seat pricing hides well, and the exit, which is only ever as easy as the data export you tested before signing.
For a company thinking of building one, the useful reframing is that SaaS is a business model rather than a deployment method. The application is necessary and insufficient. What makes it work is multi-tenancy designed in from the start, billing that handles the awkward cases, support somebody actually staffs, and evidence that customers will pay before the platform gets built.
