The SaaS apocalypse. Every app is dead. We’ll build everything with AI. That claim felt overblown to me from the start, and I still don’t buy it. Some SaaS products will disappear. AI tools will absorb some features, and in some cases buying an off-the-shelf product will stop making sense. But that doesn’t add up to the end of software as a service. It changes which services we need, how we use them, and how we decide they’re worth paying for.
I can already see the change in my own work. I know why I pay for particular tools, what they do well, and why I need them in my stack. I don’t need their UI for that. If a service reliably delivers what I need, my last login stops being a useful measure of its value. And I think that opens up room for a lot of smaller, focused applications.
The market is changing. It hasn’t disappeared.
Public data gives us plenty of reasons to question the current shape of SaaS. But SaaS Capital’s survey published in 2026, covering more than 1,000 private B2B SaaS companies, reported median growth of 22% for 2025, down from 25% the year before. Slower growth is still growth. That sample isn’t the whole market, and it certainly doesn’t prove today’s vendors will win the next round. Still, calling the entire category dead doesn’t make much sense to me when part of it continues to post numbers like these.
The question I care more about is what customers will keep paying for. A screen they spend an hour in every day? Or a capability that gets work done every day? Those have often come packaged together. With an agent between the person and the application, they can come apart: the service can be useful even when its user can’t remember what the dashboard looks like.
Just because an agent can do something doesn’t mean it should
In chess, I can capture an opponent’s piece and still make a bad move. I see AI the same way. An agent’s ability to complete a task doesn’t tell me whether it makes sense to hand it that task every time. A model can be excellent at interpreting an unclear brief, connecting information, or choosing a tool. Once I know the exact rules for a calculation, ordinary code often makes more sense: fast, predictable, and straightforward.
Take invoice processing. An agent can work out which document I need from a conversation, find it, and hand it to the right service. But checking totals, detecting an exact duplicate, or generating an accounting export doesn’t have to involve fresh model reasoning at every step. A service can have defined inputs, validation rules, and documented errors. It may still use AI where it helps, such as reading an unusual document. Having AI available is no reason to call it for everything.
Anthropic’s guidance on building agents describes a similar principle: start with the simplest solution that works, and account for the added cost and latency agents can bring. To me, that’s a practical argument for specialized services sticking around. The agent decides what needs doing and calls software built to do it.
OpenAI’s practical guide to building AI agents takes a similar approach. It recommends agents for ambiguous tasks, complex decisions, or unstructured data where conventional automation struggles. Without that need, a deterministic solution may be enough. The guide also describes an agent as a combination of a model, tools, and instructions: something that uses functions and APIs from existing systems. That division makes sense to me. A more capable model expands the work I can delegate; good tools let it actually finish the job.
I also distinguish two different costs: using AI to write a program, and needing AI every time that program runs. If Codex helps me build a data check that then runs as ordinary code, I used AI during development without paying for fresh model reasoning over every row. That combination interests me for smaller services: lower the cost of creating them while keeping operations inexpensive and predictable.
A small application can solve a hard problem
That’s why I expect a boom in micro SaaS. I don’t mean everyone will have to build ten apps and maintain them for the rest of their lives. I mean more narrowly focused services that people and companies pay for because they do one thing well. A narrow scope doesn’t make the problem trivial. Checking data before an accounting export, managing permissions, or processing a sensitive document can be a small part of a workflow and still be where mistakes get expensive.
A tool like that doesn’t need an environment I want to spend the whole morning in. It needs to explain what it does, give the agent safe access, and return usable results. My agent sends it work, changes settings, or updates data for the task at hand. I get the result, an exception that needs attention, or a decision to make. I don’t have to open five more apps and carry the same context between them.
Cheaper development can also produce a pile of interchangeable products nobody wants to pay for. Being small isn’t an advantage by itself. I see value in a focused problem, knowledge of its awkward details, and reliable operations. That can still be worth paying for when the first version of the code is cheap.
Codex gives me reasons to use more tools
My experience with Codex points somewhere more interesting than replacing one app with another. What matters is that I don’t have to start over every time I move between tools. I used to open the right application, find the right place, and translate what I wanted into the way that application worked. When an agent handles that, I can stay focused on the task and the result. The service it uses still does its part.
OpenAI is developing that direction through Codex plugins, which connect apps, instructions, and workflows for different roles. The examples go beyond writing code to working with company documents, analyzing information, and preparing materials. What interests me is the connection to tools a company already uses. Their data and capabilities get another way to be useful without moving everything into a single new application.
Imagine preparing for a customer meeting. I need to know what we promised, what’s still open, and whether anything has changed since the last meeting. An agent can gather material from several services and prepare a briefing. Afterward, it can propose a record update and follow-up tasks. The CRM still holds the customer history, permissions, and deal structure. The task tool still tracks deadlines and progress. My not opening them personally doesn’t mean they’ve stopped being used.
That also changes how I think about software fragmentation. Today, another app often means another password, another menu, and another place to check. If an agent handles much of that interaction, using several specialists becomes more manageable. Access, integrations, and responsibility for data still need attention, but some of the daily switching goes away. That could give smaller services an opening previously blocked by people’s understandable reluctance to learn yet another tool.
Building it in an evening and running it for years are different jobs
There’s a real shift toward building in-house, too. In McKinsey’s August 2026 survey, 32% of respondents said their organizations had forgone buying at least one software product or feature because they could build it internally with coding agents. That’s a strong signal that AI is already affecting build-versus-buy decisions.
Some of those decisions will make excellent sense. I suspect some also reflect the current AI fever. When everyone keeps saying you can build an app in an evening and SaaS is finished, it’s understandable that companies want to see what they can make themselves. But I’d be careful about treating excitement over a quick prototype as evidence of what long-term operations will look like.
Building an app for myself, rolling it out across a company, and maintaining it for years are different jobs. A prototype can get by with one account and sample data. In a company, someone has to handle departing employees, permissions, changes to connected systems, recovery after failures, and outputs that look correct but aren’t. Security and personal data requirements exist for a reason. AI can make that work substantially cheaper, too. Responsibility for the result remains.
So a subscription isn’t just the price of code I might be able to generate. I’m also paying for someone who understands the problem, keeps dealing with its exceptions, and keeps the service running. I can handle some things more economically myself. For others, I’m happy to pay someone who solves them for multiple customers and doesn’t have to learn them from scratch just for me.
The more work we delegate, the more oversight matters
For businesses, I expect systems that make actions traceable to become more valuable. I need to see what happened, when, who or what triggered it, and which rules applied. If an agent changes a setting or sends data elsewhere, the only explanation shouldn’t be buried in a chat history. The service should preserve state and a traceable record of operations, enforce permission boundaries, and reject requests that break its rules.
A log alone doesn’t guarantee correctness. It can document a bad operation perfectly. It becomes useful alongside validation, access controls, and a way to recover from mistakes. That’s another reason I wouldn’t leave every detail to a model’s discretion. If a step must meet exact conditions, I want the system to enforce them. The agent can handle context and coordination; the service also needs to be able to say, “I won’t do that.”
Interfaces don’t have to disappear. They’ll remain useful for investigating problems, setting rules, and making more involved decisions. OpenAI demonstrates this with apps in ChatGPT and the Apps SDK: a service can offer its functions and an interactive interface inside a conversation while keeping its own backend. Interactive tools in Claude work along similar lines. My argument doesn’t require UI to cease existing. It only requires that routine work no longer makes me visit it.
The product changes for SaaS builders, too
If I were building a specialized service today, I’d consider agent access from the beginning. Putting an API on the side and declaring the product ready isn’t enough. An agent needs to understand the operation, what inputs it requires, and exactly what came back. A rejected request should explain why. An accepted request should make clear whether the work is finished or merely queued. Otherwise, the agent starts guessing at a state it doesn’t actually know.
For a document export, for example, I want to know whether the export was created, which documents it includes, and which failed. If the connection drops and the agent retries, the service shouldn’t blindly create a duplicate operation. These aren’t flashy product-video features. They may be exactly why I’m willing to pay: someone has thought through the situations a first working demo doesn’t reveal.
I also expect vendors to change how they show value. If an agent does most of the interacting, the number of active human users tells only part of the story. I’ll care about successfully completed tasks, processing speed, work I don’t have to correct, and cost per result. That doesn’t mean everything has to be billed per action. A subscription can still make sense when I know what it keeps delivering.
So what will I pay for?
Next time I consider canceling a service, “When did I last open it?” won’t be enough. I’ll want to know what work it did for me, how reliably it did it, and what I’d have to take over if I switched it off. SaaS builders will need to demonstrate value beyond their own screens. A record of completed work and resolved exceptions may be more useful to me than every effort to pull me back into a dashboard.
I don’t expect today’s SaaS products to carry on untouched. I expect the reasons we pay for them to change substantially. Some applications will disappear; others will form around problems that haven’t made sense to serve on their own. My bet is that plenty will be small services I want close at hand, even if I almost never see their interfaces. They’ll earn their keep through the work they do.