SaaS Isn't Dying: It's Dissolving

Over the past year, at the companies I work with, I recommended they stop paying for almost every software subscription. Not to swap them for cheaper ones: we replaced them with custom apps, built in days with the help of AI. What I learned doing it isn't a cost-cutting technique. It's a clue to how the entire software industry is being reorganized.

The buzzword is "the death of SaaS." I think that's imprecise. SaaS isn't going to vanish overnight, like an extinct species. It's going to dissolve: its functions will keep existing, but spread between each company's own code and a few base platforms. What dies is the idea that generic software, sold per user, is the natural way to solve a business problem.

This essay explains why that's happening, what survives and what it means for those who sell software today, including the AI startups that believe they're on the winning side.

---

Why SaaS existed

SaaS rested on a simple economic fact: building software was expensive. An inventory system, a CRM or a metrics dashboard took months of work and a team of engineers. For a small business, that was unaffordable. For a large company, it was a distraction from its real business.

SaaS solved that problem by splitting the cost. One company builds the system once and rents it to thousands of customers. Each customer pays a fraction of the development, and the provider profits from scale. It was a good deal for both sides, which is why it dominated for two decades.

But it's worth noticing what was actually being bought. You weren't paying for the software itself, but for avoiding the cost of building it. The subscription price was, at bottom, the price of not having to hire a team. When that cost changes, the whole deal changes with it.

---

What changed

The cost of building custom software collapsed. Today one person with a coding agent can stand up in days what used to take a team months. I'm not talking about toy prototypes: I'm talking about tools that real teams use every day to operate.

This isn't an incremental improvement. It's a change of category. When something goes from costing months to costing days, it stops being an investment you have to justify and becomes just another operating decision. You no longer ask "is it worth building this?" but "why am I still paying for this?".

The markets understood it before many companies did. Between January and February 2026, the massive sell-off of software stocks that got dubbed the "SaaSpocalypse" wiped out nearly a trillion dollars in value. Not because revenue had fallen, but because investors saw that the foundation of the model, the cost of building, was evaporating.

---

Generic software was always a compromise

Every SaaS is designed for the average customer, who doesn't exist. To serve thousands of different companies, the product piles up features you don't use and lacks the two or three you actually need. You pay for 100% and use 30%.

Worse still, you end up adapting your business to the software instead of the other way around. Your processes bend to fit the fields, flows and reports the vendor decided on. For years we accepted this as the unavoidable price of not building.

When I built these tools for my clients, what surprised me most wasn't the savings. It was the fit. Each app does exactly what that operation needs, in the vocabulary of that business, and nothing more. It's simpler software than the SaaS it replaces, and that's precisely why it works better.

That's the part the debate tends to overlook. Custom development doesn't win by being cheaper. It wins because it eliminates the core compromise of the generic model. I told this through a concrete case in why I recommended a custom CRM instead of buying one.

---

What doesn't dissolve

It would be dishonest to say I recommended eliminating everything. At those companies we kept the ERP and the eCommerce CMS, and not out of laziness. There's a layer of software that's not worth building in-house, and understanding where that line sits is the most important lesson of this essay.

That layer has three traits:

• It's the system of record. Inventory, accounting, orders: the source of truth everything else rests on. An error there isn't an annoyance, it's a financial problem.
• It carries external obligations. Electronic invoicing, taxes, payments, data protection. The rules change and someone else defines them. Keeping up is permanent work that nobody wants to do alone.
• It demands accountability. Security, backups, auditing. When something fails, someone has to answer for it.

The rule I came away with is this: build what's specific to your business and cheap to maintain; pay for what's costly to get wrong. What survives of SaaS isn't the interface or the features. It's reliability, compliance and accountability.

And that layer is changing too. When every company builds its own tools on top, what's valued in the base is no longer its screen, but its APIs, its permissions and its audit trail. The SaaS that survives looks less like an application and more like infrastructure.

---

What it means for those who sell software

Many AI startups see themselves as the ones who will kill SaaS. Most of them are SaaS. A customer-service chatbot or an AI visualization dashboard, billed monthly, is exactly the type of product I described above. And it's among the easiest to replicate, because it's usually a thin layer over a model anyone can license.

The uncomfortable question is a direct one: if my customers replaced their SaaS in weeks, how long would yours take to replace you? The same agent that lets you build fast lets your customer build without you.

The defense isn't having the best interface. It's in what a homegrown build can't improvise:

• Proprietary data that improves with use. A product that learns from thousands of cases has something an app built in a week doesn't.
• Deep integration. The more embedded you are in the customer's operation, the more expensive it is to remove you.
• Charging for results. If you charge per case resolved and not per license, you compete against the cost of the problem, not the cost of building a copy.
• Industry knowledge. Knowing what to build is scarcer than knowing how to build it.
• Accountability. Security, reliability and someone who answers for it. Exactly what custom development tends to neglect.

In short: you have to sell what sits on the side of the layer that doesn't dissolve.

---

From product to craft

For twenty years, software was a product: something made once and sold many times. What's coming looks more like a craft. Every company will have software made to its measure, the way they once had tailored suits or handmade furniture, only now the workshop costs almost nothing.

In that world, the advantage doesn't belong to whoever knows how to code. It belongs to whoever understands the business well enough to know what to build, and is honest enough to recognize what isn't worth building.

Software became cheap. What remains expensive is having the data, knowing which problem is worth solving and taking responsibility for making it work.