SaaS Is Dying. Here's How To Thrive Anyway

Software-as-a-service was the monumental revolution that happened as the technology industry gave birth to the cloud, and the cloud, in turn, grew to maturity.

Instead of paying for annual software licenses, which you would install onto company systems and maintain yourself, you paid for cloud software, where installation and maintenance were mere details that no longer concern you or your IT department.

Once revolutionary, however, SaaS is now the dinosaur in the room, and until the advent of AI, it wasn't exactly clear what the world-ending meteor would be, or if there would even be one. Now that AI is here, however, it is clear that SaaS, as it was designed and priced in the past, is living on borrowed time.

To survive, or thrive, in the AI era, your own company's SaaS needs modernization. In the pre-cloud era, some companies "modernized" by moving their software into virtual machines, and slapping thin clients on top (you know who you are). But the true winners, both then and now, are the ones who deeply understand the shift and take bold risks to completely reinvent themselves for the new era.

This post is geared at those innovative companies.

Why SaaS Is In Trouble

SaaS was designed for information workers, and comes in all manner of shapes and sizes: marketing platforms to create content, publish or send it, and measure responses for further optimization; office suites to create and collaborate on documents, slides, and spreadsheets; customer-relationship management solutions, to support sales processes as leads move from top of the funnel to conversion and nurturing; and a million other types of applications.

An uncharitable characterization of much SaaS would be as a console-like button-mashing user-interface to twiddle bits in databases. It's uncharitable because this characterization ignores the judgement and expertise required to mash those buttons in ways useful to a business. But it's accurate in the sense that much of the "SaaS work" that we do does not require judgement or expertise, and could easily be delegated to assistants given the correct standard operating procedures.

AI rapidly moved from simple chat-like applications that could create lame jokes and short stories to highly capable assistants, which can build and execute software (often invisibly, without an end-user knowing). These assistants, though lacking our judgement and expertise in many cases, are extraordinarily capable of button-mashing, and can work on tedious problems at inhumane paces for an indefinitely long time.

SaaS is in trouble precisely because today's AI agents are increasingly adept at performing the work that our SaaS applications were designed to allow humans to perform. But these SaaS applications were not designed for agents: they were designed for humans, and so they have clunky user interfaces, low-level APIs (where they even have them), and in many cases don't have any functionality a coding agent couldn't write from scratch in a matter of hours.

Some humans have demanded command-line interfaces for popular SaaS applications, so they can control them with their agents. Some companies have been proactive in providing such interfaces, even while not fully understanding where things are going.

I'm here to tell you where things are going and how you can get ahead of the curve.

The New Role of Humans

If machines are doing our button-mashing for us, then the natural question is: do we even need humans, and if so, what for? The answer to that question must provide a clue as to how the landscape of SaaS applications will evolve over time. In turn, this clue is the key to understanding how companies can ensure they are not displaced overnight by vibe-coded upstarts who demonstrate a keen understanding of AI-native requirements.

Software engineers are ahead of the curve here, because the first truly and deeply useful kind of agent was a coding agent. As software engineers, we have watched as AI went from being a novelty to a genuinely indispensable tool for crafting software.

As a software engineer myself, I've watched as my role has gone from typing characters into a terminal editor, to directing, orchestrating, supervising, and reviewing an army of coding agents. I'm no longer a musician playing an instrument. I'm the conductor who's responsible for the entire symphony.

Software engineering had its button-mashing interface, and it was the IDE or code editor. A year ago, nearly every engineer I knew worked in one all day. Today, most of my work happens elsewhere.

The tools we use facilitate orchestration, supervision, and review, and they not only integrate with the agents we use, but they bring AI to bear on the new set of problems we face, ranging from knowing when our agents are going off track (active supervision) to how well they are doing the job we asked them to do (code review).

If this is the future of all information workers, not just software engineers, then it means two things become inescapable:

1. Humans are still necessary, though the role they perform changes from musician to conductor; they no longer mash buttons, but they do direct the button-mashers and use tools to shape and supervise the button-mashers.
2. The button-mashing interfaces for all other information workers are in danger of dying as fast as the IDE and code editor have died, and will likely be replaced by something unrecognizably different.

Many companies, sensing imminent danger, have taken a step which may be necessary in the short-term, but is, at best, only a stalling tactic.

Buying More Time

Many tools have proliferated to allow AI to mash the very buttons that SaaS requires us to mash. These tools show the demand for AI-native control of the functionality that is built into these SaaS applications, and they point the way to a short-term solution.

Every SaaS vendor should be producing a new surface (or refining an existing surface, such as an SDK or an API) specifically for agents, to allow agents to perform everything that can be done through the legacy user interface.

Agent interfaces do not look like human interfaces, precisely because agents are not humans. They more closely resemble programming interfaces (such as SDKs or command-line tools, or simpler tool interfaces like MCP), because agents are built on language models, and programming is also language-based.

A number of vendors have introduced command-line tools for their SaaS applications, ranging from Notion to Salesforce. These tools enable humans who are using agentic software like Claude Desktop or ChatGPT Desktop to use these applications in a first-class way, without having to go through the screen, mouse, and keyboard.

Because companies are already bought into these SaaS applications, because not everyone is using agents (and therefore, the button-mashing interfaces are still required), and finally, because these SaaS applications hold onto a large amount of business data, which is not easily extracted, these command-line tools are staving off defection, and making both human users and agentic users happy enough.

For now. But that will soon change.

Beyond the SaaS CLI

The tool that allows an agent to control a browser is a massive hack, but transiently necessary in a world being transformed. The tool that lets an agent directly drive the features of a SaaS app is much less of a hack, but it's still a hack, and one that cannot last forever.

The reason is that a massive portion of a SaaS application is defined by a UI and its backend support: the APIs that are consumed by the UI. Without the UI, and all of the infrastructure needed to support it, across all of the platforms it is delivered on, the absolute size, and therefore value, of a SaaS application is dramatically reduced.

Beyond just the UI support, most Enterprise SaaS apps have a massive layer of complexity that is caused by their support for customization: and this, in turn, is caused because they must deliver the same app to all customers, rather than write one-offs on the fly for every different customer use case.

Without UI and its support, and the layers of customization complexity, a CRM application like Salesforce.com becomes a little custom code running on a Postgres database. An email marketing application like Mailchimp becomes a one-off script and some HTML/CSS that uses AWS Simple Email Service. Almost every SaaS application becomes a little custom glue code written atop cloud services.

That's a scary thought, at least for any SaaS vendor.

Now you might think that a SaaS vendor's lock on customer data might provide a way to keep them subscribed, even as the world around them becomes ad hoc code written on-the-fly by agents for specific use cases like customer-relationship management.

That's definitely not true in the way you think: no matter how tight a grip a SaaS vendor has on its customer's data, if that data can be seen by a human inside the SaaS app, it can be extracted by an agent. Usage limits can slow down extraction, but they cannot stop it.

The New SaaS

Every business wants a moat, and although data is a moat, AI has made it easy to fill that moat in with dirt, one shovelful at a time, and faster than anyone could have predicted.

If SaaS vendors do nothing, they die through startups, possibly even the frontier AI companies, who are busy tapping their powerful and proprietary models to conquer new domains.

If SaaS vendors add a CLI or other agent interface, they survive the transitionary period, but can they emerge on the other side victorious, or is the agentic interface only life-support for a dying man?

I believe it is possible for SaaS vendors to not just survive, but to actually thrive in the AI era. Doing so requires completely rethinking the very concept of "software-as-a-service", and seeing past these transitionary years, where one might be convinced that nothing at all needs to change, because, hey, "Customers keep paying so far, and agents can always use our legacy user-interfaces!"

To prepare themselves for the coming shift, SaaS vendors need to deeply internalize three facts:

• The value of all code is shrinking to zero
• Most SaaS vendors will NOT own any significant human touchpoint
• Data becomes a moat only if it powers agentic information work

I'll briefly discuss these points below.

Code Is Worthless

The typical successful SaaS application is many millions of lines of code, spread throughout dozens of separate backend services, and separate web and mobile GUIs.

Previously, such code was a moat, because to replicate this functionality, a competitor or a customer would have to recreate a significant chunk of this code, which would take many years.

Increasingly, AI is capable of rapidly replicating software. And unlike a successful SaaS application, such replication can take numerous shortcuts, because the vast majority of customers don't use the vast majority of features, and much complexity is caused by scaling constraints, which are irrelevant for new competitors and customers.

Even though it's a simplification of the truth, the right mental model to adopt is that code itself is worthless. In the coming world, it can be created quickly and cheaply by anyone, including customers with no engineering team.

Most SaaS GUIs Are Dead

In five years, is a person in marketing going to be clicking buttons around an email marketing solution like Mailchimp, carefully writing copy for the next email campaign, and spending hours on formatting, selecting target lists, performing QA across devices and platforms, and so forth?

The answer is no. The marketing person will dictate direction of campaigns and have high-level input into messaging, special promotions, and so forth, but will serve as both conductor and judge, not a button masher.

While this still leaves a role for Mailchimp, it is not clear the GUI is part of this. The marketing person may in fact be interacting with a general-purpose AI front-end, such as Claude or ChatGPT, which then seamlessly uses the features of Mailchimp through MCP Server or other machine-native interfaces.

Many SaaS vendors will try to continue owning the human touchpoint, but as humans stop touching all of these points, most of them must necessarily fail, and this is a serious point of risk for a SaaS vendor.

If the marketing person is no longer even aware that Mailchimp is being used, how sticky can Mailchimp be? Switching providers to a different email marketing platform could be as easy as clicking a button, which implies a race to the cheapest provider (which will invariably be owned by cloud infrastructure companies).

If SaaS vendors want to own a human touchpoint, then they need a reason why a human would want to use that GUI, as opposed to outsourcing its usage to AI agents, and there are not many good reasons for doing so.

That said, specialty visualization, including iterative visualization driven by human-AI interaction, is a good reason for the time being, in domains where that makes sense (and a great example is AI video direction).

Agentified Data Is the New Moat

Companies have long tried to use data as a competitive moat, and they will continue to do so in the AI era.

The danger is lazily thinking that because a SaaS platform has "customer data", and it is not easy to extract this data, therefore the platform has a "competitive moat" and will possess staying power.

As mentioned before, this is now less true than ever, as it becomes possible to spin up armies of agents to extract data from systems designed to make data extraction difficult. For a time, one can play the game of imposing API rate limits, or trying to otherwise detect AI data extraction, but ultimately such techniques will fail.

It's not enough to have a tight grip on a customer's data. SaaS vendors must go beyond data custody as a moat and use their data assets to drive real value for their customers.

What this looks like depends very much on the domain, but since I have been using Mailchimp as an example, I will explain how a moat can be created for Mailchimp.

Even though each Mailchimp customer can access their own data, they cannot access each other's data, and for good reason.

Yet, across all of Mailchimp's 13 million users, there is a tremendous amount of closed data (which no frontier model has access to) on what sorts of emails are being created for different domains, and which campaigns are more or less successful and why.

That data can sit there, doing absolutely nothing, or it can be "agentified" to drive new value creation for Mailchimp customers.

If we are Mailchimp, how do we agentify our vast pools of closed data? We do it by building our own models, agents and tools, which are powered by this data, in order to solve customer problems.

An example would be a copywriting and design agent that can write copy and design layout that it knows to be effective, which a general-purpose AI like Claude or ChatGPT cannot know, because it does not have access to the closed data that Mailchimp has access to.

Such an agent could end up being called by Claude or ChatGPT as a tool: and, if we are Mailchimp and our customers want to use us that way, then we should support this access pattern rather than try to fight against it. But we are still indispensable because if a customer does not use our agent for copywriting and design, then their engagement and interaction rates will be vastly lower.

That's a kind of moat that can survive the race to the bottom, and represents the most defensible strategy for many SaaS vendors to thrive in a post-AI era.

Summary

SaaS is in trouble because the people who used to mash its buttons are becoming conductors, and their orchestras don't need today's plethora of special-cased GUIs.

A CLI or MCP server buys a SaaS vendor time, but it can't save an application whose value was mostly interface, customization, and code that agents can now write in an afternoon.

The lesson to SaaS vendors is clear: agentify your data now, while you still have it, before someone else's agents make you irrelevant.

Get Started

If you're a SaaS vendor working out how to agentify your data, talk to an engineer →