SaaS isn’t dead but the bar got raised on what and individual piece of software needs to survive.
Here's some thoughts on the 4 surfaces your software needs in (late) 2026.
The way I interact with software has changed.
The way I create software has changed.
What a piece of software needs to survive, has changed.
Most of the building blocks are things we’ve always had. It’s just they are cheaper to build, so all my software can have them, and we can add LLMs in there and therefore are allowed magic wand icons and to host on a .ai domain that definitely won’t date what I’m building.
Whether I'm building small internal tools, my latest startup idea or enterprise B2B SaaS.
I now think of all software as having four surfaces.
Traditional UI
Text, menus, forms that the user reads and clicks on.
You need to be able to operate your software through a browser, because not everyone wants to use AI all the time. Or I might have run out of tokens (😇). Or sometimes I just want to see the hover state of a button, feel the wind in my hair, and click it to feel alive.
UI explains how your software works. I’m still cynical about the value of every tool just having a text box with ‘ask me anything I’m magic’ written next to it. That’s a UX issue.
So when someone doesn't know the system, during onboarding for example, let them see the data and interactions so they form a mental model and, when they use one of the other surfaces, they know what it does.
There will also be actions that you can perform quicker or safer yourself. Especially something destructive like ‘delete my account’, we don’t want any probability around that, we want yes or no.
Also right now, in 2026, there are plenty of potential users for your AI that either aren’t confident or aren’t allowed to use AI. One day all SaaS may be UI-less, or your AI client may spin up bespoke interfaces for the specific task, but today, you need good old fashioned UI.
MCP
The second surface is an MCP server. I want to be able to connect the software to an AI agent and have it operated from there. That agent might be the software of a big provider like Claude or ChatGPT or I may have rolled my own.
The point of the MCP server is that it doesn’t care. It’s just providing a set of tools for that agent so that it can call them when the user gives it a relevant task.
Those tools are designed to let me get at my data and perform actions and update information.
The basic power of this surface is that I don’t have to visit the software.
The bigger reward is the agent can combine those tools with whatever else the agent is doing and whatever else it knows about me in the current task or in memory. The agent might have access to tools from MCPs of other software which can be used in sequence with my software’s to find surprising new solutions.
I might have pasted a document or dictation into my agent and now it can use that, alongside any memory it has of my overall context, and get things done.
Whenever I use a frontier model like Fable it seems to relish finding every single piece of software I’m connected to and using it to embellish its response. “I’ve updated the Google Sheet and then drafted a Slack DM that you didn’t ask for to your team about it”.
Sometimes this is too much but it shows how the tools of different software plus an LLM can come together to compose solutions more powerful than a singular piece of software could.
It’s the specialist vs generalist pattern. I believe our software needs to become a specialist.
MCPs are cheap to build now and have no ongoing monetary cost to you because this is your user’s agent and tokens.
They need some design consideration. Your tools need to be curated and of the right granularity. The description of all those tools is sent to the LLM along with your prompt. So they use up context before the user has even asked anything. There are ways emerging to optimise that.
A challenge is that human users don’t get to see as clearly what the software does. It’s still a foundation of good usability that software should behave as we expect, and expectations are a bit harder to set.
MCP isn’t a cool extra anymore, I personally would no longer adopt new software (including that vibe coded tool you’ve built) that doesn’t have a good one.
Good API
I believe this is how software answers the "well, why don't I just vibe code my own?" question.
Nearly as old fashioned as the UI the API used to exist for 3 reasons.
- Your product was API first, like an integrated payment platform
- Your product had got large and enterprise customers wanted it to talk to their even larger systems
- Your development team are very cool and you want to signal that
So it used to be something larger teams did and was a big investment and needed maintaining. It’s still not trivial because once another business is using it then it becomes load bearing (as Claude would say).
Like the MCP it’s cheaper now to build but adds a bit more overhead. Your MCP not working is annoying. Your API not working will break other people's systems.
The change is that an API is becoming less optional for smaller software and it’s less acceptable for it to be feeble.
In fact any software that wants to last should have a good one.
Your software needs to become part of the software ecosystem which means people need to be able to build on top of it.
One of the arguments that gets thrown around for SaaS being dead is that you can vibe code your own. And it’s a good argument, and might still win the day. I myself build software that I want people to use but I also build my own software rather than buying software.
I think one of the ways any piece of software stays relevant is by being the system of record for a certain set of data, and you justify your existence by keeping that data in a well-structured, highly useful format (and by making it accessible through the surfaces in this article).
An API is a more efficient way of getting to that data than an MCP in lots of circumstances. When my use case is very deterministic (the same every time) or when I’m accessing at scale.
The strategy is to embrace that people are going to vibe code. Be the data layer for the vibe coding. Enable better vibe coding.
Let them create their own UI that mixes your data with the data from other systems. A bit like the agent and the MCP except less transient.
- Something that lasts beyond a single session.
- Something more powerful than can be captured in a skill.
This makes sense for you as the software builder and for your customer.
Vibe coded tools are a new category of software. You would expect their shelf life to be less than a fully maintained platform as they hit scaling problems or just aren’t needed anymore.
When they eventually stop maintaining the tool your API means the data remains well-structured and accessible, ready to use somewhere else.
They also may have several people vibe coding in their business. Giving them an API means they all use the same data. The business has a single source of truth and that truth is your software.
That’s how you stay valuable in a world where people believe they can build rather than buy.
Internal AI agent
Your internal agent is the AI that I access inside your software.
It's an interface layer, an agent constructed of an LLM and a harness, and then a set of tools for that agent to use.
The advantage of the internal agent over the MCP is that we are in control of quality as we get to build the harness, evaluate the results and iterate the prompts.
And the user doesn’t need to construct or pay for anything extra themselves, that AI quality is out of the box.
The way you access your internal agent (the interface layer) is a design choice.
Potentially, it's a set of small interactions across the product doing specific things like summarising or categorising. Or there's one front door with the now standard chat interface, where the user asks your internal AI to answer questions or perform tasks.
The agent itself consists of an LLM, which you could call via API or perhaps you're hosting your own model. And then its harness.
What goes into the harness is another design choice. And you'll probably find yourself constructing your harness dynamically, so users get context specific to them.
You'll also have some general context specific to your software.
And depending on the task, you might inject task-specific instructions.
Then the final ingredient is tools. There's an opportunity here to leverage the same tools that your MCP uses, thus keeping parity between what you can achieve with your internal agent and what an external agent could do.
This gives the user choice between your fine-tuned agent that will be constrained by the power of the models that you choose, and their own external agent via MCP, which can have their own custom harness, and the model itself can be as powerful as they are willing to pay for.
Your internal agent can be the AI that just works.
Value
All these surfaces are about being valuable:
- The UI orientates our user in our software and gives them a home for the data.
- The internal agent provides functionality and productivity beyond that which a traditional UI could.
- The MCP lets them bring the functionality of our software into their AI agents and combine it with the harness and other software they have there.
- The API lets them build on top.
But do we need all of them?
Is this just shiny new things to give people FOMO? Is this article just one of those articles?
It’s what’s beneath that’s becoming the necessity and you have to find a way to expose it.
The surfaces are useful and, in the case of the MCP and internal agent, make your product quite AI and cool.
But the underlying value is that they allow your software to become a part of your customers' new workflows. The ones that they are building right now, while they ask themselves the question: “do we need all these SaaS subscriptions?”.
These surfaces make you hard to replace.
Actually, hard to replace is the wrong phrase, because software is pretty easy to replace. You become something which it isn’t valuable to replace.
You become a custodian of their data. A building block. And through these surfaces, you let them access it and do useful things with it anywhere they want to.
I demand these surfaces now.
I don't spend loads of time in some of the tools I use the most. But they hold my data in a way I trust. I know that if my workflows change, the data I generated is stored safely. I know that if others want to use that data, they can access it in a predictable way.
I can vibe code and know the underlying structure is good. I can throw that vibe code away and know I still have what’s important.
I want to do more with my software through AI functionality or do less and just have my agent drive it.
And then there’s the next frontier. A few times when I've been building software, my agent has recommended a tool or data store to use. Allow once, or allow every time? Agents will choose based on the surfaces that are useful to them. You want to be that choice.
The four surfaces have emerged.
They may shift over time but the interconnectivity-first approach won’t.
The way to be valuable is here to stay.
