
Core thesis: the current state of LLMs does not replace durable software systems. It makes the intent layer on top of those systems much smarter.
The market reaction is not the product story
Over the last few weeks, maybe 10 or so, we have seen a strong capital markets reaction around the beloved segment of Software as a Service. The category that was loved for its relatively non-linear operating costs has seen its multiples deflate lately.
I agree with the idea that markets are somewhat efficient, and this may be some kind of healthy correction. But I do not agree with the narrative I have seen in the media and across X, where people describe this as a SaaS apocalypse.
That narrative misunderstands where the current state of LLMs fits best in the product stack and in the user experience.
LLMs belong on the intent surface
As I have argued before, a beautiful user experience requires consistent outcomes. Inherently probabilistic engines will not generate that kind of output consistently.
What they will become instead is a smarter layer on the intent surface.
LLMs may be the best technology we will see in the next hundred years for:
- Sentiment analysis
- Semantic search
- Intent matching between a user and an algorithm
But that does not mean they are inherently the most efficient or best way to generate consistent outcomes inside a state machine.
Consistency still belongs to deterministic systems
There are other architectures, including ordinary computer architectures, that are better suited for consistency. In the long run, millions of users will not use LLMs in production to run the same operations you can type into a calculator app, because that is not efficient.
Maybe for trivial examples, like two plus two, you can add some kind of caching to your LLM inference system.
But for the most part, there are thousands of use cases where a two-line C algorithm will be orders of magnitude more performant than running the same computation through LLM-based systems.
Why this matters for SaaS
The main issue is that current multiples are downplaying truly good software products that took enormous expertise and time to perfect, treating them as if they were easily inferred algorithms and executions.
Take SAP as an example. Anyone working in a transnational company knows SAP is a very special piece of software that can take months to configure.
That is not because SAP lacks intelligence. It is because these are embedded systems that operate very close to real-world interactions and generate accounting information, among other things.
Even if LLMs can generate code at a certain pace, and even if code written once can be reused many times, this does not mean every computation inside a context window replaces the state machine and interfaces created by SAP.
I use this example because it comes from a couple of industries I understand, but the same pattern must show up across many industries.
The correction is not an apocalypse
Maybe this was a healthy correction. Still, I do not think we are seeing a SaaS apocalypse.
In the worst case, over the medium to long term, less optimized players in software will become stale and may eventually be replaced by other software companies.
But they will not be replaced by some person running AI in a basement, because that is not how far you can get today.
The companies that outperform will be the ones that:
- Adapt best to the new way of writing code
- Provide reliable services at the best prices
- Compose easily with a broader stack of applications and software
The better integration pattern
For consumers of Software as a Service companies, it absolutely does not make sense to build your own version of QuickBooks just to integrate your system with something like TurboTax.
In many cases, the better use of time will be:
- Use an LLM-first API to generate or interpret accounting records.
- Use an LLM to create the correct transactions in the system.
- Let a stateful, well-designed product like QuickBooks or SAP preserve reliability and consistency.
That is probably the best user experience you can get.
On one side, you get the reliability of stateful software. On the other side, you get a better interface.
Instead of memorizing a whole account structure, your interface can become intent-based. In accounting systems, a Chart of Accounts works like a key-value map: one side stores the account, and the other defines what belongs in it. I do not think users should have to memorize that anymore.
You should be able to use a text-first or voice-first interface and say, “I want to sell 10 bikes for x amount.” Then the system should send the correct request to the API endpoint.
That is what peak integration will look like.
Do not bet against all SaaS
So do not bet against every Software as a Service company.
If anything, in the long term, the best companies may be better off as the total addressable market evolves. Watch for the companies that are adapting: the ones that are not doing massive tech layoffs, but are instead growing their technology teams so they can keep up with agents and the agentic software systems we want to build today and tomorrow.
That is all I think. Thank you so much.
Originally published on LinkedIn.