SaaS stands for Software as a Service: software you access over the internet and pay for by subscription, without installing it or maintaining the servers it runs on. If you've used Gmail, Spotify, Netflix, Zoom, or Canva, you've used SaaS — you just probably never thought of it that way, because it's become the default way software works rather than a special category. The acronym gets thrown around in tech conversations as if it needs no explanation, but the underlying idea is genuinely simple once it's broken down layer by layer, which is exactly what this explainer sets out to do.
Imagine three ways to get from renting an apartment to owning a house, mapped onto computing: you can rent a fully furnished apartment and just live in it (that's SaaS — someone else built and maintains everything, you just use it). You can rent an empty apartment and furnish it yourself (that's PaaS, Platform as a Service — the building and utilities are handled, but you bring your own setup). Or you can buy raw land and build the whole structure yourself (that's IaaS, Infrastructure as a Service — you get the computing resources, and everything above that is your responsibility).
With SaaS, the vendor handles literally everything below the application layer — servers, databases, security patches, scaling. You open a browser, log in, and the software works. Examples: Salesforce (CRM), Slack (messaging), Dropbox (storage), Shopify (e-commerce). If you're a non-technical business user, SaaS is almost certainly the category you interact with daily, even if you've never heard the acronym.
Worth noting: the acronym itself is younger than the practice it describes. Businesses were renting access to hosted applications over networks before the term "SaaS" was standardized in the early 2000s — the label came after the pattern had already started to spread, which is common with technology terminology in general. What matters for understanding the term today isn't its exact origin, just that it now covers the overwhelming majority of business software sold to companies of any size.
PaaS gives developers a ready-made environment to build and deploy applications without managing the underlying servers. Vercel, Heroku, and Render are common examples — a developer pushes code, and the platform handles deployment, scaling, and infrastructure. PaaS sits in between SaaS and IaaS: more control than a finished app, less responsibility than raw infrastructure. Most companies building their own SaaS product will use a PaaS to actually deploy it.
IaaS is the rawest layer — virtual servers, storage, and networking, rented by the hour or month, with no application or platform layer included. AWS EC2, Google Compute Engine, and DigitalOcean Droplets are IaaS. Whoever uses it is responsible for the operating system, security configuration, and everything running on top. This is the domain of infrastructure engineers, not typical end users.
To extend the apartment analogy one step further: at the IaaS level, you're not just furnishing an empty apartment, you're pouring the foundation and wiring the electrical yourself. That's an enormous amount of control — you can configure literally anything about the environment — but it also means every security patch, every scaling decision, and every piece of downtime is entirely your responsibility to catch and fix. Most businesses never touch this layer directly; it's typically only companies with the technical staff to justify managing infrastructure themselves, usually because they need cost control or configuration flexibility that a PaaS doesn't offer.
| Layer | You manage | Vendor manages | Example |
|---|---|---|---|
| SaaS | Just your data and usage | Everything else | Gmail, Slack, Notion |
| PaaS | Your application code | Servers, deployment, scaling | Vercel, Heroku |
| IaaS | OS, security, application, everything above hardware | Physical servers, networking | AWS EC2, DigitalOcean |
Beyond trivia, the distinction matters because it tells you where responsibility sits if something breaks. If a SaaS tool has an outage, that's entirely the vendor's problem to fix. If your own application (built on a PaaS or IaaS) goes down, some or all of the responsibility for diagnosing and fixing it is yours. Understanding which layer you're operating at clarifies what you're actually paying for — and what you're still on the hook for even after paying. It also clarifies what a vendor's support team can and can't help with — a SaaS provider's support line can fix a bug in their application, but they have no visibility into a bug in code you deployed yourself on top of their PaaS or IaaS offering.
Before any of these existed, "on-premise" software was the default: you bought a license, installed it on your own hardware, and managed absolutely everything yourself, forever. Some industries with strict data residency or compliance requirements (certain government, defense, and healthcare contexts) still run on-premise software today specifically because they can't or won't put sensitive data on someone else's servers — it's worth knowing this option still exists, even though SaaS has become the default everywhere else.
People sometimes assume SaaS necessarily means "cheaper" than owning software outright, and that isn't reliably true. A subscription paid every month for years can, and often does, add up to more than a one-time license would have cost — the appeal of SaaS isn't that it's always cheaper, it's that it converts a large unpredictable upfront cost into a smaller predictable recurring one, and bundles in maintenance and updates that would otherwise be a separate cost and a separate headache. Whether that trade is worth it depends entirely on how long you'll use the software and how much you value not having to manage it yourself.
Another common mix-up: "cloud storage" like Dropbox or Google Drive gets casually called "cloud computing" as if it's a separate thing from SaaS, when it's actually a straightforward SaaS example — a hosted application (file storage and sync) delivered over the internet on a subscription. The confusion usually comes from cloud storage feeling more like a utility than "software," but architecturally it fits the SaaS definition exactly.
Only if it requires an account, runs on the developer's servers, and involves ongoing access (often subscription-based). A one-time-purchase offline app isn't SaaS, since there's no ongoing service relationship. Most modern subscription apps with cloud sync — a note-taking app, a fitness tracker with a paid tier — do count as SaaS, just delivered through a mobile app instead of a browser.
Very commonly, yes. A typical company might use Slack and Salesforce (SaaS) for internal tools, Vercel (PaaS) to deploy its own product, and AWS (IaaS) to run a database or background job server the PaaS doesn't cover. The three layers aren't mutually exclusive — most real tech stacks blend them.
Start as high up the stack as your requirements allow. If a PaaS like Vercel or Render can run your application, use it — it eliminates infrastructure work entirely. Only drop down to IaaS when you have a specific need a PaaS can't meet (unusual compliance requirements, highly custom server configuration, or cost optimization at a scale where the PaaS markup becomes significant).