The idea that AI will end every app and we will build everything ourselves felt overblown to me from the start. Some SaaS products will disappear, and AI tools will absorb some features. But I do not see that as the end of software as a service. I see a change in the work we need from a service and how we use it.
I can already see the change in my work. I spend less time in the cloud interfaces where I host applications and in tools for working with code. Often, I mainly open the resulting site or app to check how it works. The agent handles configuration or editing.
Notion is the clearest example for me. I rarely write notes manually now: I dictate them to an agent, and it saves them with the relevant projects. I use Notion more than before while spending less time in it myself. Its readability still matters. When I open it, I can find my way around and make changes myself. My agent can work with it, too. Those two ways of using the service complement each other.
The market is changing. It hasn’t disappeared.
SaaS Capital’s survey published in 2026 reported median growth of 22% for 2025 across more than 1,000 private B2B SaaS companies. A separate annual sample reported 25% for 2024. That is slower growth, but still growth. These samples do not represent the whole market or guarantee today’s vendors a future. They do show why calling the whole category dead feels inaccurate to me.
I am therefore interested in the work customers will keep paying for. We have often associated the result with the screen where it was produced. If an agent handles the interaction, a service can remain useful even when its user almost never opens the dashboard.
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.
Codex plugins offer a similar path. They connect apps, instructions, and workflows for different roles, including analysis and preparation of materials. What matters to me is that they use tools and data a company already has.
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.
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 guide recommends agents where conventional automation struggles with ambiguity, complex decisions, or unstructured data. It describes them as a model, tools, and instructions. That division makes sense to me: the model chooses the approach, and existing software performs its individual steps.
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 is why I expect more micro SaaS: small services focused on one need. This is my bet on the future. A narrow scope does not make the problem easy. Checking an accounting export or managing permissions may be a small part of the overall process and still be where errors become expensive.
A service like this needs to describe its operations, give the agent safe access, and return a usable result. The agent requests work within its permissions. I receive the output, an exception to handle, or a question I need to decide. I do not have to open another app for every routine step.
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.
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 sense. I suspect some also reflect excitement over a quick prototype. A prototype does not yet tell us how much work long-term operations will require. Nor does the survey say companies stopped paying for 32% of their software; it concerns skipping at least one purchase.
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.
Building your own system also depends on the technical knowledge of whoever will maintain it. They need to understand backups, security, databases, and application operations; a more complex tool also calls for an understanding of usability. Generating code quickly does not supply that knowledge by itself.
I would be especially careful with critical work. Customer relationships are a good example for me: before building my own CRM, I would want to know what the existing options fail to solve and whether that justifies taking on all the maintenance. An established tool has already addressed many of these situations. If it fits, paying for the service can save me from work that the first prototype does not reveal.
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 traceable operations to become more valuable. When an agent changes a setting or sends data, I want to know what it did, when, and under which rule. The explanation should not live only in a chat. The service needs to preserve state and operation history, enforce permissions, 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 would design agent access from the start. Each operation needs to explain its required inputs and outputs. A rejected request should give a reason. An accepted request should distinguish finished work from work waiting to be processed. Otherwise, the agent will guess at a state it does not 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.
My bet is that some new services will be smaller and more focused. I will want to use them even if I almost never see their interfaces. What matters is the work they reliably do for me.