Software as a service was built around a simple operating assumption: People use software.
A company hires more employees, buys more seats and gives those employees applications that help them complete work faster. The software provider gets recurring revenue. The customer gets leverage from the workforce it already has.
Artificial intelligence is beginning to break that assumption.
When an AI agent can inspect data, make a decision and take action across multiple systems, the customer no longer needs software only to help a person perform a task. The software itself can increasingly perform part of the task.
That is why the anxiety around a potential “SaaSpocalypse” is more significant than another technology-sector selloff. The Wall Street Journal reported Friday that software companies ranging from startups to established public firms are reorganizing, rebuilding and, in some cases, starting over as generative AI erodes products built around narrow administrative and knowledge-work tasks.
But I do not think the central question is whether AI will kill SaaS.
The more useful question is what happens when the unit of value in software shifts from access to a tool to completion of work.
The vulnerable layer is the human-operated workflow
For much of the SaaS era, product design followed the organizational chart.
Salespeople had sales software. Recruiters had recruiting software. Marketers had marketing software. Finance teams had finance software. Each category added dashboards, forms, alerts and workflows that made an employee more productive inside a defined job.
That model created enormous companies because every additional employee could become another license.
AI agents invert part of that logic.
If software can now read a pipeline, identify deteriorating deals, update customer records, assemble a forecast and alert a manager without requiring a person to click through each step, the value no longer sits primarily in the interface.
It sits in the system’s ability to understand context, make the right decision and execute safely.
This distinction explains why simply adding a chatbot or an AI button to an existing product can be insufficient. The customer is not necessarily asking for a faster way to use the old workflow. The customer may be asking why the old workflow still exists.
Rattle’s pivot is a useful case study
The Journal’s reporting centers in part on Rattle, a sales-software startup that raised nearly $30 million and was valued at more than $100 million before generative AI began automating the administrative work around which its product had been built.
Founder Sahil Aggarwal initially tried adding AI to the existing product. Eventually, the company cut its workforce sharply, stopped selling the original product and rebuilt around a new AI-native platform called Von.
That pivot is more interesting than the startup drama.
Von describes itself not as another application a revenue-operations employee uses, but as an AI RevOps layer that connects to CRM data, calls, email, calendars and warehouses and returns finished work. It can write information back into systems such as Salesforce while respecting permissions and requesting confirmation before changes.
That is an architectural change, not a feature release.
Rattle helped people operate a workflow. Von is being designed to perform substantial portions of the workflow itself.
For operators, that difference is the whole story.
AI creates a pricing problem as well as a product problem
The software industry has spent decades perfecting per-seat economics.
That becomes awkward when the product’s main promise is that fewer people can produce more work.
Suppose a customer once needed 20 employees and 20 software licenses to handle a process. If AI enables 10 employees to handle the same volume, a vendor that continues charging only by seat may have created enormous customer value while shrinking its own addressable revenue inside the account.
At the same time, AI-intensive products introduce meaningful inference and infrastructure costs that conventional SaaS products often did not carry at the same level.
So the vendor can face pressure from both directions: fewer human seats on one side and higher variable compute costs on the other.
This is why the argument about outcome-based pricing is more than a new packaging strategy.
HFS Research found that 62% of surveyed Global 2000 enterprises wanted to renegotiate SaaS contracts. HFS has increasingly described the emerging model as “services as software,” in which pricing moves away from seats and features and toward consumption or business outcomes.
That transition will not be clean. Outcomes are harder to define, baseline and attribute than user licenses.
But the economic logic is clear: If the product is selling completed work, the commercial model eventually has to reflect the value of the work rather than the number of humans who touched the interface.
Not every SaaS company needs to burn the product down
The most dramatic stories will naturally involve companies that shut down products or rebuild from scratch.
That does not mean every established software company is doomed by technical debt.
The better dividing line is whether AI changes the core workflow enough that the existing architecture prevents the company from delivering the new outcome.
Some established software businesses are showing that reinvention can happen inside an existing company.
Gong said in May that annual recurring revenue had passed $500 million while its most recent quarterly growth rate exceeded 55% year over year as it expanded around revenue AI. Those are company-reported figures, but they demonstrate that AI adoption is not automatically destructive to an incumbent software model.
Intercom took a different route. It built the Fin AI customer-service agent alongside its established customer-service platform. Salesforce agreed in June to acquire Fin for about $3.6 billion, according to Intercom.
The common thread is not simply that both companies “added AI.”
They moved closer to owning the work the customer wanted completed.
Systems of record still matter
There is a tendency to assume that if AI can generate an interface or reproduce a feature quickly, the underlying software company has no moat.
That is too simple.
Enterprise software is not valuable only because of what appears on the screen.
It can contain years of structured business data, permission models, compliance controls, transaction histories, integrations, approval logic and embedded operating rules. Replacing a dashboard may be easy. Replacing a trusted system of record inside a regulated or complex organization can be very difficult.
AI may therefore strengthen some software layers while weakening others.
Thin applications whose primary value is organizing a narrow task are more exposed because an agent may reproduce that task using models and APIs.
Platforms that hold authoritative data, control permissions or sit directly in the transaction path may become more important because agents need reliable systems on which to act.
The future stack could contain fewer interfaces without containing fewer systems.
The moat moves from features to context and authority
Feature velocity used to be one of the clearest competitive advantages in software.
AI-assisted coding is reducing the cost and time required to reproduce many features. That makes a long feature list a weaker defense than it once was.
The more durable questions are different.
What does the product know that a general-purpose model does not?
What systems can it access?
What actions is it trusted to take?
How well does it understand the customer’s operating context?
Can it prove what it did and why?
Can it improve from the outcomes of previous actions?
Those are much harder capabilities to clone than a dashboard.
They also connect directly to governance. An AI system that can complete work needs permissions, auditability, exception handling and clear human escalation paths. A company cannot responsibly automate a process by simply giving an agent unrestricted access and hoping the model behaves.
The operational control layer becomes part of the product.
Every SaaS company should run a different kind of product review
If I were operating a software company today, I would not begin with the question, “Where can we add AI?”
I would begin with the workflow.
If the interface disappeared tomorrow and an AI agent could call every relevant API directly, what value would still belong uniquely to us?
Which steps exist because a human historically had to perform them, and which steps exist because the business genuinely requires judgment, authorization or control?
What result does the customer actually want when they buy our product?
Can we move closer to delivering that result rather than making the customer operate the machinery?
And if we succeed, does our pricing model reward us for creating that efficiency or punish us for reducing seats?
Those questions are uncomfortable because they can lead to answers that invalidate parts of the existing roadmap.
That is still better than protecting a roadmap for a workflow the customer may soon stop needing.
The SaaS model is not disappearing. Its operating assumption is changing.
Software is not going away because of AI.
If anything, businesses may depend on more software infrastructure as autonomous systems require data, APIs, security controls, identity, permissions, orchestration and observability.
What is under pressure is a particular version of software economics: the idea that value scales primarily with the number of humans who log in.
The next generation of enterprise products may be judged less by how many users they help and more by how much reliable work they complete.
That changes product architecture.
It changes pricing.
It changes staffing.
It changes what buyers consider a moat.
And it changes the question every software company has to answer.
The old question was whether the product made a worker more productive.
The new question is how much of the work the product can safely own.