I don’t buy the idea that SaaS is dead because someone can now generate an application with AI.
If a product solves a problem someone cares about, at a price that makes sense to them, there is still a reason to pay for it. The tools used to build it do not make that value disappear.
That does not mean every useful product will sell. People need to find it, understand it and trust it. The problem needs to matter enough to justify the cost. Those are difficult questions, but they are more useful than declaring an entire way of delivering software finished.
What bothers me about the slogan is how quickly it skips the customer. The conversation becomes about what a model can generate, while the person trying to get something done disappears from view.
What is supposed to be dead?
There are different arguments hiding inside the same phrase. Some people mean AI will make certain features easier to copy. Others expect agents to replace the screens people use today. Another version says customers will build their own tools rather than subscribe to someone else’s.
Each deserves a different response. A feature becoming easier to reproduce can weaken a product’s advantage. A different interface can change how a service reaches its users. Building internally can be the right decision for a particular team.
None of those possibilities establishes that people will stop paying someone else to provide useful software.
For example, Microsoft’s CoreAI announcement describes agents changing SaaS application categories and the way applications are built. I read that as an argument for a changing software market, not proof that the need for software businesses disappears.
There is room to take the change seriously without accepting the most dramatic conclusion attached to it.
The customer has a problem, not a technology thesis
Imagine a small service business trying to manage appointments. Its customers need to find a suitable time, receive a confirmation, and change a booking without a long exchange of messages. The business needs to avoid conflicts and know what is happening tomorrow.
The useful part of a booking product is that this workflow gets handled. Whether its developer wrote every line manually or used an agent is not what makes the appointment arrive on the calendar.
If an existing service handles the workflow well, paying for it can be an entirely sensible choice. Being technically able to create an alternative does not mean the business wants to spend its attention doing that.
The same applies to a product that looks simple from the outside. A small interface can remove a recurring annoyance. A focused tool can make a task easier than a larger system does. Usefulness does not have to arrive with an impressive feature list.
That is the question I would rather ask about an idea: whose work becomes easier when this exists, and is the improvement meaningful enough for them to choose it?
A demo is only one part of the product
I understand why fast prototyping makes the argument convincing. Seeing a working screen appear from a description is impressive. It can also make an existing product look much easier to replace than it felt to build.
But the screen leaves out a lot. What happens when an external service fails? Does the information stay consistent after a partial update? Can a user recover from a mistake? Will the workflow still make sense when someone other than the developer uses it?
Those questions do not become irrelevant because generating the first implementation gets easier. Better tools can help with them too. Someone still needs to decide what acceptable behaviour is, check that it happens, and deal with the cases that were missed.
A customer buying a service can be paying for that continuing responsibility as well as the feature they came for. A business choosing to build internally is taking on that responsibility itself. Both choices can make sense. Neither follows automatically from a convincing demo.
AI is useful when it improves the result
I am not arguing against using AI in products. I care about whether it helps someone complete the task.
Prefilling a form from information a user has already provided can reduce repetitive work. Helping someone find relevant information can be valuable. Generating more output that they then have to verify, organise and correct can add work instead.
The label tells me very little on its own. I want to know what the feature improves, where it falls short, and what the user has to do when its output is wrong.
The same standard should apply to a product without an AI feature. A conventional search box, a clear dashboard or a dependable notification can be exactly what the workflow needs. There is no reason to make the experience more complicated just to make the product sound current.
I would rather use a straightforward tool that handles my problem well than an ambitious one that leaves me doing the difficult part myself.
Useful does not mean guaranteed to sell
This is where I would put a limit on my own argument. Building something useful is not a guarantee of demand, and demand is not a guarantee that a particular subscription price will work.
A person can appreciate a feature without needing it often enough to pay monthly. A team can recognise the benefit and still prefer a tool it already uses. A product can solve the problem but make switching too difficult to justify.
Those objections deserve attention. They can point toward a narrower audience, a clearer offer, a better workflow or a different pricing model. Sometimes they mean the idea is not worth continuing.
AI can make the competitive pressure more immediate. If a product’s entire value is a small feature that a customer can easily reproduce or get elsewhere, I would take that seriously. I would look for a stronger reason for the product to exist rather than assume the subscription itself deserves protection.
But a weak reason to buy one product is not evidence that nobody will buy software.
Build something worth choosing
For me, the practical response is to stay close to the problem. Talk to the people who experience it. Watch where the workflow breaks. Find out whether the thing I am building actually helps, rather than treating a successful implementation as the end of the discussion.
That leaves plenty of room to use better tools, change the interface or reconsider how the product is sold. I do not need to defend every existing SaaS product to believe there is still a place for useful new ones.
People have work they want to get done. If a product helps them do it well and the price is worth it to them, paying for it still makes sense.
That is a much better starting point for building something than deciding whether SaaS is dead.