Counting up from zero
There are now more than 10,000 LLM-based SaaS startups in the United States. The number varies depending on how one defines the category, but the broad point holds. The market has filled quickly.
This raises two fairly simple questions.
Do all of these companies offer genuinely differentiated value?
And do enterprises actually need hundreds of SaaS tools and vendors in order to function?
I think that the answer to both is no.
That conclusion does not require cynicism about the technology. Large language models are genuinely useful. Entire categories of software will exist because of them. Some companies already provide real, durable value.
But the current ecosystem also contains a large amount of software whose core functionality can be replicated with a prompt, a short script, or a thin layer on top of a general-purpose model or harness.
The wrapper debate
There is a familiar argument in the AI startup world about “wrappers.” The term is usually used dismissively to describe products that sit on top of frontier models like GPT, Claude, or Gemini.
I’m not particularly interested in that framing. I build a tool myself that relies on foundational models and harnesses.
Almost every piece of modern software is, in some sense, a wrapper around something else. Databases wrap storage engines. Web applications wrap operating systems and networking stacks. The entire SaaS industry is composed of abstractions layered on other abstractions.
The real question is not whether a product is a wrapper.
The question is whether it creates value that the underlying system does not provide by default.
A good wrapper performs several functions simultaneously. It packages capabilities into a workflow. It removes friction. It encodes domain knowledge. It handles edge cases that raw models do not handle well. And it continues to improve as the product team learns how customers actually use it.
In other words, it turns a raw capability into a tool that people can rely on.
Those products can be useful.
But the bar for differentiation should still be high.
If a product can be reproduced by a reasonably competent engineer with a prompt template, a few hundred lines of code, and an orchestration harness like Claude Code or a simple internal toolchain, the moat is thin.
Not nonexistent. But thin.
The hidden cost of the tool zoo
Enterprises rarely evaluate tools in isolation. They accumulate them.
Over the last fifteen years, the dominant model of enterprise software has been additive. A team discovers a new tool that solves a local problem. Procurement approves it. The organization moves on.
Repeat this process often enough and you end up with what many companies quietly maintain: a SaaS tool zoo.
Each individual purchase can be justified. Taken together, they create a system that is far more complex than it needs to be.
The direct costs are obvious. Licensing fees add up quickly. According to several SaaS management studies, mid-sized enterprises often maintain well over 100 separate SaaS subscriptions across departments.1
The indirect costs are less visible and usually more significant.
Every new tool requires some degree of integration work. Data has to flow in and out of it. Authentication has to be configured. Someone has to manage permissions.
Staff need to learn the interface. Documentation needs to be written. Processes evolve around the tool.
Then there are switching costs. Once a team becomes accustomed to a particular system, even a mediocre one, replacing it becomes politically and operationally difficult.
Security and compliance teams face their own version of the problem. Every additional vendor expands the organization’s attack surface. Each one introduces another external system handling corporate data, credentials, or APIs.
None of these burdens are catastrophic on their own. The issue is accumulation.
They compound quietly over time and tax the entire organization.
AI may accelerate the problem
LLMs make it unusually easy to create new software tools.
A small team can now build products that would previously have required much larger engineering efforts. This is a positive development in many ways. It lowers barriers to experimentation and allows niche problems to be addressed more quickly.
But it also increases the rate at which new tools appear.
If the SaaS era produced dozens of overlapping applications for things like project management or CRM extensions, the LLM era may produce hundreds of micro-tools aimed at narrower slices of work: document summarization, proposal generation, compliance drafting, customer support triage, and so on.
Many of these products will work well. The question is whether they deserve a permanent place inside an enterprise stack.
A tool that saves five minutes per week for a small team may not justify the operational weight it introduces.
A provocative mental model
One way to approach this problem is to invert the usual framing.
Most organizations ask some version of the following question:
Which tools should we cut?
That framing assumes the current stack is the default state. The task becomes one of pruning.
A more useful mental model, albeit a slightly provocative one, is to start from zero.
Zero vendors.
Zero subscriptions.
Just self-hosted inference and an internal harness.
Imagine that your organization has access to the underlying models and the ability to write lightweight internal software. Nothing else.
Then ask a different question:
What is the first external tool we absolutely need?
Not “which one is convenient.” Not “which one has a good sales pitch.”
Which one is indispensable?
Once that tool is identified, ask the same question again.
What is the second tool that truly deserves to exist in the stack?
Then the third.
Instead of counting down from a tool zoo, you count up from zero.
This forces a different kind of evaluation. Each addition must justify its existence against the baseline of building the capability internally or relying directly on the underlying models.
Many products will fail that test. A smaller number will pass it easily.
Those are the ones worth keeping.
What survives the zero baseline
Tools that survive this exercise usually share certain characteristics.
They embed deep domain expertise that is difficult to replicate quickly.
They manage complex workflows involving many users, systems, or data sources.
They handle reliability, compliance, or operational guarantees that are expensive to reproduce internally.
Or they create network effects that make the product more valuable as more participants join.
These are real forms of differentiation. They are not easily replaced by a prompt or a script.
A great deal of AI software will eventually converge toward this kind of value. But the market is still early, and experimentation tends to produce a lot of thin abstractions before it produces durable platforms.
Counting up, not down
The point of the zero baseline is not just austerity.
Organizations should absolutely adopt new tools when they provide clear advantages. Avoiding useful technology out of principle is its own form of inefficiency.
The point is simply to change the default posture.
Instead of assuming that every new AI tool deserves a place in the stack unless proven otherwise, assume the opposite.
Start with nothing.
Then count upward carefully.
Most of the software ecosystem will eventually sort itself out through competition and consolidation. It always does. In the meantime, enterprises can impose their own discipline by asking a very simple question each time a new tool appears:
Does this deserve to exist in our stack?
If the answer is unclear, it probably doesn’t.
For example, studies by BetterCloud and Zylo regularly report that mid-sized companies manage dozens to hundreds of SaaS applications across departments.
