SaaS stands for Software as a Service: finished software you use over the internet without installing or maintaining it, paid for by subscription rather than owned by licence.
That is the definition, and it takes ten seconds. The reason people keep searching for it is that the term arrives in a sentence next to PaaS and IaaS, and the interesting question is not what the letters expand to but where the line between the three actually falls.
The useful way to understand them is as a ladder of responsibility. Each rung hands more of the stack to somebody else, and the practical question for any project is which rung you want to be standing on.
Table of contents
- The three-layer ladder
- What Software as a Service actually changed
- Where the responsibility line actually falls
- Choosing a rung when you are building rather than buying
- The other acronyms, briefly
- How this fits the rest of the stack
- FAQ
The three-layer ladder
Start from running software yourself on your own hardware. Everything is yours: the building, the machine, the operating system, the runtime, the application, the data.
IaaS, Infrastructure as a Service. You rent virtualised hardware. The provider handles the physical machines, the network and the hypervisor. You handle everything from the operating system upwards: patching, the runtime, the web server, the database, the application, backups, monitoring. A virtual private server sits here.
PaaS, Platform as a Service. You bring the application code and the provider runs everything under it. Operating system, runtime, scaling, certificates, and often a managed database. You still own your code and your data model, and you no longer own the machine.
SaaS, Software as a Service. You bring nothing but your data and configuration. The software is written, hosted and operated by someone else. Your email, your accounting package, your CRM.
The unifying question at every rung: what breaks at 3am, and whose phone rings? On IaaS it is yours. On PaaS it is yours only if the code is wrong. On SaaS it is somebody else’s entirely.
What Software as a Service actually changed
The delivery model gets the attention, but the substantive changes were commercial and operational.
- Subscription instead of a licence. You stop buying a version and start renting access. Cheaper to start, more expensive over a long enough horizon, and much easier to leave.
- Multi-tenancy. One running instance serves many customers, with data separated logically. This is what makes the economics work, and it is the source of the noisy-neighbour and data-isolation questions that follow.
- Continuous updates. Everyone runs the current version. No upgrade projects, and no ability to stay on the version that worked.
- The vendor operates it. Uptime, backups, security patching and scaling are contractual rather than internal, which is the whole value and also the whole risk.
That third point deserves more attention than it gets. Continuous updates mean you cannot pin behaviour. A vendor can change a workflow you have trained thirty people on, and your only lever is feedback. This is a real cost of the model, not a footnote.
Where the responsibility line actually falls
The phrase that matters when buying SaaS is the shared responsibility model, and the common misreading is assuming the vendor covers more than they do.
The vendor is responsible for the application, the infrastructure, availability, and the security of the platform itself.
You are responsible for a shorter but sharper list: who has access to your account, whether those accounts have multi-factor authentication, what permissions each user holds, what data you put in, whether you have an export, and compliance with the regulations that apply to your business rather than to the vendor’s.
The great majority of SaaS-related breaches sit squarely in your half. Not the vendor being compromised: an employee account without multi-factor authentication, an over-permissioned integration token, a sharing link set to anyone with the URL. Those are configuration, and configuration is yours.
Ask two questions of any SaaS vendor before you depend on them. Can I export all of my data in a usable format, unassisted, today? And what is the actual recovery point objective, meaning how much data would I lose in the worst case? Vague answers to either are informative.
Choosing a rung when you are building rather than buying
If you are shipping a product rather than purchasing one, the ladder is a choice about where your team’s attention goes.
Choose IaaS when you have a genuine requirement the layer above cannot meet: specific hardware, an unusual runtime, a compliance rule about the machine itself, or existing operational expertise you want to use. Also when you need to know that no abstraction sits between you and the kernel.
Choose PaaS when your differentiator is the application, and server administration is overhead rather than skill you are selling. Which describes most product teams honestly assessed.
Choose SaaS for anything that is not your product. Nobody has ever won a market by self-hosting their own email or their own issue tracker, and the hours spent doing it were hours not spent on the thing customers pay for.
The failure mode worth naming is choosing IaaS by default because it feels more serious, then spending a quarter rebuilding the parts of a platform that were available as configuration. On RunxBuild the platform rung means a repository connection, a build log, a live route, environment variables, runtime logs, metrics and a rollback, with managed MySQL and Postgres beside it. The services documentation covers the supported runtimes.
The other acronyms, briefly
The pattern spawned a long tail of terms, most of which are marketing rather than architecture. The few worth recognising:
- FaaS, Functions as a Service. You deploy individual functions rather than a service. Scales to zero, bills per invocation, and creates cold starts and connection-pool arithmetic you would not otherwise have.
- DBaaS, Database as a Service. A managed database instance. Provisioning, patching, backups and often replication handled for you, with the schema and the queries still yours.
- BaaS, Backend as a Service. Authentication, storage and a data API assembled so a client application needs no server of its own. Fast to start, and the trade is that your data model lives inside somebody else’s product.
- Anything else as a Service. Usually a product category, not an architectural layer. Treat the term as a description rather than a decision.
The ladder itself is the durable idea. The rest is naming.
How this fits the rest of the stack
The choice between renting hardware and renting a platform is mostly a question of where you want your team’s hours to go, and that comparison is easier when both sides are priced rather than described. The RunxBuild hosting calculator prices the platform side across services, databases, storage and bandwidth, which makes the trade-off against a self-managed equivalent a number rather than an opinion.
Useful related references:
- SaaS Meaning: The Definition and What It Implies Technically
- SaaS Company: What One Actually Runs Under the Hood
- Application Service Providers: ASP, SaaS, MSP, and the Lineage
- Services on RunxBuild
FAQ
What is the full form of SaaS?
Software as a Service. It describes finished software delivered over the internet, hosted and operated by the vendor, paid for by subscription rather than bought as a licence and installed on your own machines.
What is the difference between SaaS, PaaS and IaaS?
They are rungs on a ladder of responsibility. IaaS gives you virtualised hardware and you manage everything above the hypervisor. PaaS runs the operating system and runtime so you supply only application code. SaaS is finished software where you supply only data and configuration.
Is Gmail SaaS?
Yes. It is finished software you access over the internet, hosted and operated by the vendor, where you provide only your data and settings. It is one of the clearest everyday examples of the model.
Who is responsible for security in a SaaS application?
Both parties, split along a defined line. The vendor secures the application and infrastructure. You control who has access, whether multi-factor authentication is enforced, what permissions each account holds, what data you upload, and your own regulatory compliance. Most incidents originate on the customer side of that line.
Is SaaS cheaper than self-hosting?
Usually cheaper to start and often more expensive at large scale, but the comparison is misleading if it only counts subscription against server cost. Self-hosting adds patching, backups, monitoring and incident response, and those recurring hours are the line item most often left out.