SaaS stands for Software as a Service, and it means you rent software that runs on somebody else’s machines instead of buying a copy and installing it on your own. The standard definition lives in NIST Special Publication 800-145 (September 2011), a seven-page document, and the odd thing about it is that the SaaS entry is written as a list of what you do not manage rather than a list of what you get.
Why the official definition reads like a list of chores you skip
Because that is literally the sentence. Here is the core of it:
“The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.”
No mention of dashboards. No mention of price. Billing does not even make it into the definition; it sits in footnote 1, which says this is “typically done on a pay-per-use or charge-per-use basis.”
The GSA Cloud Information Center page on SaaS writes the same idea from the other side. The provider, it says, will “handle any maintenance, like software upgrades and security patching.” Put the two documents next to each other and the picture is clean. The chores one side skips are the chores the other side owns.
So whether something counts as SaaS is not settled by its feature list. It is settled by who gets woken up when it breaks.
Why the word comes up in every software project
It marks a decision, not a concept. When a feature is needed, there are two roads: build it, or rent something that already does it. Take the second road and you have bought SaaS.
That fork sits early in the order of a software project. Somewhere in writing requirements you hit items that nobody on the team should be building from scratch. Payments. Transactional email. Login. Support tickets. That is where the word shows up. Unlike the other acronyms that fly around a planning meeting, this one is not asking to be explained. It is asking you to choose.
There is a second room where you hear it, and the meaning flips. When a team says “we’re launching as SaaS,” they mean they will stop shipping installers and start running the servers themselves. Same word, opposite end of the responsibility.
How is it different from on-premises?
The split is about where responsibility sits, not about cost. On-premises, often shortened to on-prem, means the software runs on machines you control. Buying it outright can be cheaper over five years and still be the wrong call, which is why the price comparison is the least useful part of this argument.
| Question | On-premises | SaaS |
|---|---|---|
| To start | Buy servers and licences | Create an account |
| Version | You choose it | They choose it |
| Security patches | You apply them | They apply them |
| When it breaks | You fix it | You wait |
| Missing feature | You add it | You file a request |
| When you leave | Data is already yours | Depends on their export |
The left column looks like pure cost, and it isn’t. The left column buys freedom and the right column buys time. Which one you want depends on whether that feature is the thing you are actually selling.
This blog sits on the not-SaaS side
Which means the list NIST says you do not manage exists here as actual files. This site runs on self-hosted WordPress. Using a hosted blog platform would have put us squarely in the SaaS column, but running two separate language domains pushed us onto our own server. I went and counted what that costs.
Numbers below came from logging into the server on 3 August 2026 and asking WordPress directly.
| Item | Korean site | English site |
|---|---|---|
| WordPress version | 7.0.2 | 7.0.2 |
| Plugins awaiting update | 2 | 2 |
| Plugins on auto-update | 0 | 0 |
| Hand-written feature files | 7 | 7 |
The two pending updates are identical on both sites: Site Kit 1.183.0 going to 1.184.0, and Yoast SEO 28.0 going to 28.1. Two sites means pressing the same button four times. Of the 12 installed plugins, none have auto-update switched on, so the person pressing it is me.
The seven feature files make the point better. They handle things like linking the two language versions to each other, the author box under each post, and a sidebar widget. Each file lives on both accounts, so there are really 14 copies. That phrase in the NIST definition, “or even individual application capabilities,” is a folder with seven files in it on our side.
None of this is a complaint. We wanted the things those files do, and no hosted platform was going to cross-link two domains for us. The honest reading is simpler: knowing your own version number is itself proof you are not using SaaS. Nobody blogging on a hosted platform knows what version it is running. They never need to. That is the whole product.
When comparing blog platforms I wrote that the easiest option and the most flexible option pull in opposite directions. This is the scale they were sitting on.
What about IaaS and PaaS?
They are siblings in the same document, and only the boundary moves. NIST wrote all three with the same sentence frame. With IaaS you have “control over operating systems, storage, and deployed applications.” With PaaS you do not control the infrastructure but you do control “the deployed applications.” With SaaS you control almost nothing, by design. It’s a question of how many keys to the server room you are holding. We rent a machine and administer the operating system and web server ourselves, which puts this blog on the IaaS side.
A quick test that isn’t about features
NIST lists five essential characteristics of cloud computing, and the first one makes a sharp test. On-demand self-service says a customer can provision what they need “without requiring human interaction with each service provider.”
Read that as a question. Can you sign up and be running tonight, alone, at midnight, without emailing anyone? If a salesperson has to enable your account first, whatever you are buying may still be excellent software, but it is failing the first line of the definition. The other four characteristics are broad network access, resource pooling, rapid elasticity, and measured service. Rapid elasticity is the one worth checking on the way out, because a service that scales up smoothly in a demo does not always scale back down on your invoice.
When I pick SaaS
If the feature is not something we would ever brag about, I rent it. Payments, email delivery, error tracking, a support inbox. Building those yourself produces a worse version of something that already exists, and the hours come straight out of the work that made the project worth doing.
Three things push me the other way. Data that legally cannot leave, a feature that is the product itself, and no confirmed way to get everything back out. That last one gets skipped the most, because nobody wants to discuss the breakup while signing the contract.
One question decides it faster than any comparison table. When this goes down at three in the morning, who wakes up? Answer that and the label sorts itself out.