'Vibe coding' doesn't kill SaaS: it redraws the line between what serves one and what serves many

It is worth starting by accepting the criticism before discussing it. It is true that an application born from prompts cannot hold up serving thousands of people: it lacks the layers of security, data isolation, compliance and team deployment that any serious product demands. David Hurtado does not deny this. His contribution, which is more interesting, is to point out that this objection answers a question almost no one was asking.

The article's twist consists of separating two markets we tend to confuse. There is software designed to serve the masses and there is single-user software: the tool of the freelancer, of the three-person team or of the creator themselves. And almost the entire stack claimed to be indispensable exists to solve three specific problems —scale, shared data and obligations to third parties— that the solo user simply does not have. Without those problems, role-based permissions, isolation between accounts, request limits, distribution networks or service-level agreements no longer have anyone to protect. What remains is the application and a place to store the data with a backup.

From this comes the most uncomfortable assertion for the sector, attributed to the author himself: 'single-user SaaS was subsidizing the rest.' The idea is that for years the individual has paid a subscription that financed dozens of features designed for customers they are not. The '90/10 rule' that Hurtado proposes sums it up well: if a tool covers 90% of what you need and does not charge you a license, that missing 10% rarely justifies a recurring payment. You don't compete on features; you win by removing them.

The part that deserves the most caution is the figures, and here it is necessary to attribute carefully. According to the article, the financial press spoke in February 2026 of a 'SaaSpocalypse' with some 285 billion dollars lost on the stock market, and 51% of enterprise licenses purchased would go unused. It also cites specific cases —Blinkist replacing some 60,000 dollars a year of SaaS with its own applications—, a Gartner forecast according to which 40% of new enterprise software would be built with these techniques by 2028, and a figure on Y Combinator's latest batch where one in four startups would have 95% of its code generated by AI. These are powerful signals, but it is best to read them for what they are: indications of a shift in the per-user billing model, not a death sentence. That customers withdraw licenses instead of adding them says more about how software is billed than about whether AI 'works.'

The analysis itself has the honesty to mark its limits, and there it gains credibility. It acknowledges that many people do not know what they need until they see it, and that in that preliminary work of discovery and design packaged SaaS still provides real value. And it places the boundary with surgical precision: the full stack becomes necessary again the exact moment more than one person needs to see or touch the same data. That jump, moreover, is not gradual; it happens all at once when going from one to two users.

There remains a loose end the author leaves open and that deserves emphasis, because it is where optimism must hit the brakes: security and data custody never disappear, not even in the single-user app. Storing information properly, making backups and not exposing credentials remains mandatory, and the robustness of AI-generated code is a debate still unsettled. The most useful reading of this piece is not 'SaaS is dead,' but a more nuanced and more demanding one: AI is giving each user back the ability to build exactly what they need, and that forces packaged software to justify its price on something more than features almost no one uses.