Why SaaS Will Outlive Your Obituaries
The Doomers are Burying the Wrong Thing
In 1979, Theodore Levitt - then a Harvard Business School professor - published an essay that would haunt boardrooms and airport bookstores for the next four decades. It was ostensibly an essay about railroads.
Levitt argued that the American railroad industry hadn’t actually declined because people had stopped needing to move things // each other from one place to the next. As a basic fact, that seems obvious enough. In the decades following WW2, people needed to move ~things more than ever.
The railroads declined because they had confused their tool for the job itself. To their minds, they were in the railroad business specifically, not the transportation business - and they never updated their priors. They watched in denial and polished their locomotives, as tracks and airplanes and pipelines ate their lunch.
I’ve read the various viral obituaries for software-as-a-service. I’m sure you’ve seen them too, or you’ve at least read the headlines. SaaS is dead. Vibecoding is the future. AI ate the application layer, etc.
Why pay $40 a month for a tool, when you can ask a model to build your own version of the tool, on the spot, and roll it into your token budget?
The core of modern SaaS has always been The Peculiar Bargain. Rather than buying // owning the software itself, you rent access to it on a 30-day cycle; and in exchange, the company that built it agrees to keep the lights on, keep the servers running, push out updates and absorb the maintenance burdens that used to fall on either you or your own IT department.
When Salesforce pioneered the model at the turn of the millennium - with a slogan that was literally the words “No Software” - it was a groundbreaking innovation. And when you take a step back from the base acceptance of the concept, it still is. You no longer have to install anything, patch anything, or hire a small army to keep a server farm humming in the basement; you just log in.
From 2005-2020, a lot of what we were paying for in that bargain was the difficulty of actually building software. Software was hard. It required engineers - who were expensive and scarce - along with designers, testers, infrastructure, security, etc.
A product like Basecamp was a small miracle of engineering when you considered that had to happen under the hood. And for years, the fact that software was hard to build was precisely why you’d pay someone else to have done the building. Anybody could have the idea, but the moat was the doing.
What happens when the doing becomes cheap // disposable? If a large language model can semi-reliably generate functional code, spin up a database, wire together a UI and deploy the whole shebang to the cloud in the time it takes you to describe it and make an average to decent cup of coffee, customers lose the original reason they were paying for a subscription.
I’ll concede a lot of this. The thin tools are at risk: the wrappers and the single-feature products that pushed an interface onto a problem that turns out to be (in the age of generative models) a five-minute conversation. Why subscribe to a tool that converts PDFs to spreadsheets when the model on your desktop can do it for you? A whole category of products built between ’15 and ’22 - products that raised venture $$ on the premise that a narrow workflow was worth a recurring fee - are in existential trouble, and the graveyard is going to be very crowded indeed.
But the argument that ~some SaaS is doomed doesn’t actually endorse the claim that ~all SaaS is doomed - and the people making that leap commit exactly the error Levitt pointed out in reverse. They confuse the job with the tool.
When you get past the actual building of the software, the hard part isn’t actually the code at all. It’s everything wrapped around the code - and almost none of that gets cheaper just because the code was slashed. An app that calculates a paycheck is, in the grand scheme of things, not that complicated anymore; it’s arithmetic + a lot of edge cases. What separates a company that can run payroll from an awfully clever fellow with a model is the thicket of tax compliance, across thousands of jurisdictions, and the regulatory relationships, and the legal liabilities when you get some asshole’s withholding wrong, and the integrations with banks that took years and lawyers to establish, and the simple fact that businesses run by sane men who aren’t sado-masochists don’t actually want to experiment with whether or not their staff get paid this Friday.
Customers are buying trust, and the software is simply the place where they keep it. The value in a customer relationship management system is no longer in the function of a hosted database; it’s in the years of your company’s accumulated data, the dozens of tools plugged and routed through it, the workflows your team has wrapped up in it, and the muscle memory of a dozen salespeople who’d revolt if you moved their pipeline.
Economists have a wonderfully bloodless phrase for this: switching costs. The reason your bank can offer you a checking account that pays almost zero interest while all but laughing in your face - and the reason you put up with it - is that you’d suffer more from switching than you do from staying put. SaaS companies have spent the past couple of decades building in some of the deepest switching costs in the history of commerce, and a developer with a code-generating model cannot - by typing and prompting alone - free themselves from what tech twitter seems to think is the terrible, imposing tyranny of software.
The engineers most excited about AI tend to underrate what software actually represents inside an organisation - because they think about software as mere code, while businesses think about software as a safe place to keep their promises. When a hospital buys a system to manage patient records, it’s buying a place to put liability - and with it, the assurance that when something goes wrong (and something always goes wrong) there’s a company with insurance, and a legal department, and a contract on the other end of the phone.
When a customer pays for accountability they’re buying the most valuable thing any vendor can sell; which is why the largest organisations on this rock almost never buy the cheap, flexible option. They buy the vendor who has a compliance team and an army of support staff who’ll pick up the phone at 3am and own the problem. If you hand all the responsibility back to the user, a serious enterprise will decline - no matter how clever your tooling is or how much money they’ll save. No hospital is going to use the cheap vibecoded alternative; and no hospital is going to vibecode its own tool for the same reason. They need somewhere to place both their trust and their blame.
So the question worth asking about any software company isn’t whether AI can replicate its features. Of course it can. AI can replicate almost anyone’s features, it’s table stakes. The question becomes what job the company is actually being hired to do. If that job is to perform a discrete task that a model can now perform, that company is in deep, deep shit - and they probably know it. But if the job is to be the trusted, accountable and deeply integrated system of record, where an organisation keeps something it cannot afford to lose, the founders of that company have little to fear from disposable code. They might even welcome it.
Will the margins compress? Some of them, yes. Will founders adjust their pricing? Again, yes - away from charging per seat and toward charging for outcomes, as the cost of running the software approaches zero and they find the value elsewhere. It’s worth remembering - the monthly subscription wasn’t handed down as a law of nature; founders chose it, at a particular moment, when building and hosting software cost so much that renting it out forever was the only way to recoup the expense. A handful of profitable companies have always gone against the grain - they ran their machines in their own racks, rather than renting compute power back from a landlord at a steep markup; they grew slowly and deliberately, turning a profit every single month while the rest of the industry set venture money on fire chasing scale. Everyone treated those owners as eccentrics, and charming holdouts from an older world - but they’re about to look like prophets.
Will a generation of fragile // single-feature startups get washed away in the most brutal consolidation the industry has ever seen? Absolutely - and it’ll be ugly as sin, and a lot of people who believed their wrapper was a business are about to learn it was a deprecable and duplicatable feature. But none of that is the same as going to zero, and compression is a far cry from extinction.
The SaaS doomers have read the death of a sub-category - the thin wrappers and the features inflated to the status of a company - as the death of an entire model and an entire way of doing business. They are not the same thing. Not by a long shot.
The software companies who survive will be the folks who understand that they’re as much in the “software” business as the railroad men were in the locomotive business; they’re in the trust business, the integration business, and the accountability business; they’re in the business of being the place where a company keeps the things it can’t afford to break. Those businesses are not going to zero. I’d argue they’re never going to zero. If anything, as customers find themselves drowning in other people’s cheaply generated hamburger helper code - that nobody quite trusts - they’ll pay more than ever for a vendor they can rely on, come hell, high water or lawsuits.
The code was always the cheap part; we’re only now finding out how cheap.
But everything else still costs what it costs.
And it’s broadly worth it.