I Tried to Pin Down What "SaaS" Actually Means — Turns Out Nobody Fully Agrees

 I started this because of a Reddit thread, of all things. Someone asked a simple question — what exactly counts as SaaS, technically — and the replies contradicted each other for pages. Is Twitter a SaaS? Is Airbnb? One person swore Tinder qualifies because the "product" is the connections you make, not the app itself. Another said Craigslist is technically SaaS but nobody calls it that anymore because it's become too ordinary to bother labeling. I went looking for a cleaner answer and found something more interesting: the term has a solid technical core, surrounded by a much fuzzier edge that even industry veterans argue about.

The Part Everyone Actually Agrees On

Strip away the debate, and the core definition holds up: software as a service means an application runs on someone else's infrastructure, and you access it over the internet — usually through a browser — instead of installing it on your own machine. The provider handles the servers, the security patches, the backups, the version updates. You handle logging in and using it. That's the whole transaction.

What makes this technically distinct from just "a website" is something called multi-tenant architecture. A single running instance of the software serves many different customers at once, with each customer's data kept separate through the application's own logic rather than through physically separate servers. This is why a SaaS provider can push a bug fix at 2 a.m. and every customer gets it instantly, without anyone downloading anything. It's also, according to how developers describe it on forums like r/webdev, the reason a hosted platform like WordPress.com counts as SaaS while running your own WordPress installation on your own server does not — the difference isn't the software itself, it's who owns and operates the infrastructure underneath it.

Where the Term Gets Genuinely Blurry

Here's where I stopped finding clean answers. The Reddit thread I started with kept circling around edge cases, and the more I read, the more I understood why: SaaS was originally defined in contrast to "you buy a license and install it," but a huge number of modern internet products don't fit neatly into either bucket. A calculator embedded in a subscription website counts, technically, as SaaS, according to one commenter's reasoning — it's software, it's rented, it's accessed online. But nobody would describe Netflix that way, even though it's also rented and accessed online, because the product being delivered feels like entertainment content rather than a tool. The distinction, several people argued, comes down to whether the thing you're paying for is the software's function itself, or something the software merely delivers to you.

Three Layers, Not One Category

Part of the confusion clears up once you place SaaS next to its two siblings: infrastructure as a service (IaaS) and platform as a service (PaaS). IaaS is the rawest layer — you're renting servers, storage, and networking, but you still install and manage everything above that yourself. PaaS adds a managed operating system, middleware, and development tools on top, so a team can build and deploy their own application without touching physical hardware. SaaS sits at the top of that stack: a finished, ready-to-use application where the provider has already made every infrastructure and platform decision for you. Thinking of these as layers rather than competing categories made the whole picture click for me — a SaaS provider is very often a IaaS customer of a different company one layer down.

The Trade That Nobody Advertises

The benefits of SaaS get repeated everywhere — lower upfront cost, automatic updates, access from any device, no server room to maintain. All of that is genuinely true, and it explains why SaaS became the dominant way companies deliver software over the last two decades. But I kept noticing that the same sources listing these benefits tucked a quieter cost near the bottom of the page: you don't own what you're using. Your data lives on someone else's servers, under someone else's terms of service, and if that company changes its pricing, gets acquired, or shuts down a product line, your options are limited. This is the tension Richard Stallman has pointed to for years, arguing that SaaS users can't inspect or modify the software actually running their computing, unlike with traditional installed software — a philosophical objection that most casual users never think about, but one that becomes very practical the day a vendor discontinues a tool a business has built its workflow around.

The Sprawl Nobody Planned For

The other cost that surprised me was organizational rather than philosophical. Because SaaS tools are so easy to sign up for — often with just a credit card and no IT department involved — large companies frequently end up running well over a hundred different SaaS subscriptions without any central team tracking all of them. This gets called SaaS sprawl, and it quietly creates two problems at once: wasted spending on tools nobody remembers subscribing to, and a security blind spot known as shadow IT, where software is running on a company's network that the security team never approved or even knows exists. It's a strange irony — the same ease of adoption that makes SaaS attractive is exactly what makes it hard to keep track of once an organization scales.

A Necessary Caveat

I want to be honest about a limit here: "what counts as SaaS" is not a question with a single authoritative answer, and I'm skeptical of anyone who presents it as settled. Vendors selling SaaS products have an incentive to describe the category expansively, since a broader definition makes more products sound modern and cloud-native. Meanwhile, developer communities tend to define it more narrowly and technically, focused on multi-tenancy and subscription billing rather than marketing language. Neither framing is wrong, exactly — they're answering slightly different questions. If you're deciding whether your own product qualifies as SaaS for a pitch deck, the marketing definition might matter more. If you're deciding how to architect a system, the technical definition is the one that will actually guide your decisions.

Where This Leaves Me

I didn't expect a Reddit argument about Tinder to turn into a genuine framework for thinking about software delivery, but that's roughly what happened. The useful takeaway isn't a strict checklist — it's the layered mental model: infrastructure, then platform, then finished application, each one built on the layer below it, with SaaS as the version most of us actually touch every day without noticing the layers underneath. Next time a subscription renewal email lands in my inbox, I suspect I'll actually read past the price and think about where, physically, that software is even running.