SaaS turned software from something you owned into something you rent. Here's what that actually means, why it took over, and what it changed about how products get built and sold.
If you've used Gmail, Notion, Figma, or Salesforce in the last week, you've used SaaS. You didn't install it from a CD. You didn't buy a license that lives forever on one machine. You logged in, did your work, and closed the tab. Somebody else worried about the servers.
That shift, from owning software to renting access to it, is the whole story. Everything else is detail.
The textbook definition, decoded
Software as a service is a cloud computing model where a provider delivers application software to clients while managing the physical and software resources required to run it [Source 1]. You access SaaS apps either through a web browser or through a thin locally-installed client that talks to the provider's backend [Source 1].
The phrase that does the real work in that definition is this one: SaaS separates "the possession and ownership of software from its use" [Source 1]. Read it twice. It sounds dry, but it's the pivot the entire industry rotated around.
Write for sansxel
Want your work in the Learn library? Apply for a hardlocked byline.
Before SaaS, if you wanted to use a piece of software, you possessed a copy of it. A boxed install. A license key tied to a machine. A server in your own data center running a binary you bought outright. Possession and use were the same thing.
SaaS pulled them apart. The vendor possesses the software. They run it, patch it, scale it, back it up. You just use it.
How we got here
SaaS as a recognizable category started arriving around 2000 [Source 1]. By 2023, it had become the main form of software application deployment [Source 1]. That's a roughly two-decade run from "new idea" to "default."
A few things had to be true at once for that to happen. Browsers had to get good enough to host real applications, not just documents. Bandwidth had to get cheap and reliable. Server-side infrastructure had to mature to the point where one vendor could host millions of customers without falling over. Once those pieces lined up, the economics tipped hard in favor of the rental model.
Why SaaS won the monetization fight
This is a piece in the monetization library, so let's talk about why SaaS isn't just a delivery model. It's a business model.
The old way of selling software went like this: you spent two years building version 4.0, you shipped it in a box, customers paid you a one-time license fee, and then you started building 5.0 hoping they'd upgrade in three years. Your revenue was lumpy. Customers who didn't upgrade kept using old software you couldn't fix. Piracy was a real problem because the bits were sitting on someone else's hard drive.
SaaS changes the shape of every one of those problems.
Recurring revenue. Customers pay monthly or annually. Your revenue smooths out. You can forecast next quarter with actual confidence instead of crossing your fingers about an enterprise deal closing.
Always the latest version. Because the vendor manages the software resources directly [Source 1], every customer is on the version the vendor shipped this morning. There's no "we still need to support customers on 3.7" tax.
No piracy in the traditional sense. The software runs on the vendor's machines. You can't copy what you never possessed.
Usage data. Because everything flows through the vendor's servers, the vendor sees how the product actually gets used. That feedback loop is gold for product teams.
Lower customer commitment, lower customer barrier. A $50/month subscription is an easier yes than a $5,000 perpetual license, even if the lifetime cost ends up higher. SaaS made it possible to sell sophisticated software to small teams who could never have justified the upfront cost.
The pricing patterns
Most SaaS pricing falls into a few familiar shapes:
Per-seat. You pay for each user who has access. Slack, Notion, Linear, Figma. Simple to understand, scales with the customer's team, but creates an incentive for customers to share logins.
Usage-based. You pay for what you consume. API calls, gigabytes stored, minutes of compute. AWS, Twilio, OpenAI's API. Aligns cost with value but makes bills unpredictable.
Tiered. Free, Pro, Team, Enterprise. Each tier unlocks features or limits. Most consumer-ish SaaS lives here.
Hybrid. A base subscription plus usage on top. Increasingly common because pure usage-based pricing scares procurement and pure per-seat pricing leaves money on the table.
The choice isn't cosmetic. It shapes who buys, how they buy, and how your sales team is structured. A per-seat tool can grow bottom-up inside a company one team at a time. A usage-based tool needs different instrumentation and different conversations with finance teams.
What SaaS actually demands of you as a builder
If you're shipping a SaaS product, the operational profile is different from shipping installable software. You're not done when you push the build. You're done when the request returns a 200.
A few things become non-negotiable:
Multi-tenancy. One running system serves many customers. You have to keep their data isolated, their performance from interfering, and their permissions intact. Get this wrong and you make headlines.
Uptime. When your software lives on a customer's laptop, a crash is annoying. When it lives on your servers, a crash is everyone's crash, all at once, and your support inbox lights up in real time.
Continuous deployment. Customers expect the product to improve constantly. Quarterly release cycles feel slow. Weekly is normal. Daily isn't unusual.
Observability. You can't debug what you can't see. Logs, metrics, traces. If a customer reports that something was broken at 2:14 AM, you need to be able to look.
Security and compliance. You're holding other people's data. SOC 2, ISO 27001, GDPR, HIPAA depending on what you do. This isn't optional once you start selling to anyone serious.
None of this exists in the same way when you ship a binary and walk away.
Where SaaS doesn't fit
It's the dominant model [Source 1], but it's not the only model, and it's not always the right one.
If your customers can't send their data outside their own network, SaaS is hard. Regulated industries, defense, some healthcare, some finance. They want the software to run on infrastructure they control. That's why "on-prem" and "self-hosted" deployments still exist, and why some vendors offer a hybrid where the control plane is SaaS but the data plane runs in the customer's cloud account.
If the workload is latency-sensitive in a way the public internet can't satisfy, SaaS struggles. Real-time control systems, certain kinds of trading infrastructure, anything where a round trip to a vendor's data center is too slow.
If your customer base is tiny and high-touch, the SaaS overhead (multi-tenancy, 24/7 ops, compliance) might cost more than just shipping them a thing they run themselves.
These are edge cases against the broader trend, though. The default for new application software is now SaaS [Source 1], and you generally need a specific reason to do something else.
The customer's side of the trade
From the buyer's perspective, SaaS is a trade. You give up control and you get convenience.
What you give up:
Your data lives on someone else's machines.
You're at the mercy of their uptime, their security posture, their pricing decisions.
If they get acquired and the new owner kills the product, you have a migration problem.
If they raise prices 40%, you have a budget problem.
What you get:
No servers to run.
No upgrades to schedule.
No backups to manage.
A team of people whose entire job is keeping this software working, instead of one overworked admin who has fifteen other systems to also keep alive.
For most teams, most of the time, that trade is worth it. Which is why SaaS is where it is.
A useful mental model
Think of it like the difference between owning a car and using Uber. Owning means you have the asset, you control it completely, and you also have to deal with insurance, oil changes, parking, and depreciation. Uber means you have none of the asset, you depend on the platform existing, but you also don't think about any of the maintenance. You just go where you need to go.
SaaS is Uber for software. The vendor owns the car. You're paying for the ride.
That analogy explains the appeal and the anxiety in one frame. The appeal is obvious. The anxiety is that you're trusting someone else's car, someone else's driver, and someone else's pricing model to keep working the way you need it to.
What to take away
SaaS is a delivery model where the vendor runs the software and the customer accesses it remotely [Source 1]. It separated possession from use [Source 1], which sounds philosophical but turned out to be the foundation for an entirely different way of building, selling, and pricing software. It started around 2000, and by 2023 it was the dominant deployment model for application software [Source 1].
If you're building something today, the question isn't usually "should this be SaaS?" The question is "is there a specific reason this shouldn't be SaaS?" That's how thoroughly the default flipped.
The rest of the monetization library digs into the pieces: pricing models, retention, expansion revenue, the metrics that actually matter when your revenue is recurring instead of one-shot. But it all sits on top of this one shift. Software stopped being a thing you bought and became a thing you subscribed to. Everything else followed.
