The AI SaaSpocalypse is a mirage

AI hasn’t changed what’s worth owning

In February 2026, roughly a trillion dollars in software market cap evaporated in a few weeks. Wall Street gave it a name: the SaaSpocalypse. ServiceNow, Salesforce, and Intuit are only a few of the many examples of double-digit declines year-over-year. The thesis driving these sell-offs is that if AI agents can do what enterprise software does, then enterprise software is finished. Agentic engineering lets two engineers replicate a platform in a sprint or two. Per-seat pricing collapses when one person with AI tools does the work of five. SaaS sprawl is dead. Build everything, buy nothing.

The panic is a meaningful signal, but the conclusion is wrong.

Every SaaS renewal in 2026 has a specific conversation behind it: the CFO sees the line item, taps the budget owner, and asks, “What if we just built this ourselves? AI could probably do most of the work.” That conversation is happening in every company right now, and the answers will separate the teams that look smart in 2027 from the ones that don’t. The cost of building recently dropped to the floor, but the cost of maintaining what you build didn’t drop nearly as far. Engineering leaders are revisiting the question of when to build vs buy, but the smart ones aren’t believing the SaaS obituaries.

To learn how the people making these decisions are thinking about it, we reached out to software engineering leaders and experts in the Dev Interrupted community. We also ran a DIY experiment of our own that we’ll share at the end.

AI agents haven’t changed the equation for market leaders

Rob Zuber, CTO at CircleCI, has been making the call long enough to have made every version of it. His most recent one involved evaluating new tooling for his team rather than building the capability internally:

“AI has dramatically lowered the cost of building something quickly. That means more teams can build internal tools. But the real question is no longer ‘can we build this?’ It’s ‘do we want to own this long-term?’”

That distinction matters more than it sounds. The set of things engineering teams can ship in a quarter is now enormous. Saying “we could build this” doesn’t narrow the choice anymore. Saying “we want to own this” still does.

Zuber has three filters to determine if his organization should own something new:

• Does this touch what customers actually pay you to deliver?

• What’s the cost of being wrong? Some build decisions are reversible. Others embed in your platform and become expensive to unwind.

• What’s the long-term operational cost of ownership? Companies underestimate this answer most often.

On that last point, he made a particularly sharp comment:

“The build decision gets made once. The maintenance decision gets made every day after that, usually by people who weren’t even part of the initial decision.”

When Zuber talked through that recent buy decision, he added a filter that doesn’t show up in standard frameworks: social proof. The fastest-moving software teams he respected had already converged on the same vendor, and that signal carried weight. His broader test for these decisions is whether the category is infrastructure that a vendor has already made excellent, and where you’re unlikely to meaningfully differentiate by rebuilding it. When the answer to both is yes, he argues, building intersnally tends to be about ego rather than strategy.

The counterintuitive prescription Zuber offers for the in-between cases is what makes the framework actionable in the AI era: build to learn, then decide whether to buy. He frames it as building the smallest thing that teaches you what the actual problem is, not the solution. That’s cheaper and faster than ever. Solving 20% of the problem internally isn’t always evidence that you should keep building. Sometimes it’s the opposite. It could mean you finally understand the category well enough to evaluate vendors intelligently. In his framing, the goal of an early build is learning, not permanence.

Tatyana Mamut, CEO of Wayfound, approaches the same question from the founder’s seat; she strips away much of the optionality.

“Our build vs buy is easy. If it’s part of our core product we build, and if not we buy, unless the product doesn’t exist and we HAVE to build it.”

The only exception is when the category doesn’t exist yet. For Wayfound’s own buy decisions, particularly AI agents, Mamut adds a second criterion: “They have to be able to be supervised by Wayfound and demo well to customers, since we demo all our working AI agents to prospective customers.”

Beyond the complexity of onboarding any deterministic tool to your infrastructure, talking about probabilistic ones quickly becomes complicated, especially when both ends are agents. How will they really interact with each other, and how will that evolve over time? It becomes more of a dance than ever before.

Andrea Malagodi, CTO at Sonar, brings the M&A version of the same question: sometimes build-vs-buy is really buy-vs-acquire. Sonar’s most recent call was an acquisition — picking up a team and product purpose-built for the queue between code creation and production, rather than rebuild it from scratch.

“AI has dramatically increased the volume of code being produced, but review workflows were still built for a much slower, human-paced model, so the need was immediate,” Malagodi said. “We knew where Sonar was differentiated, and we also recognized that the acquired team brought a product purpose-built for the queue between code creation and production.”

His purchasing test runs as three questions:

1. Does this help customers faster?

2. Does it strengthen the product in a durable way?

3. Does it let our teams stay focused on the parts of the stack where they have unique leverage?

If the answers are yes, he says, buying can be the more disciplined choice.

And on what he’d never build, Malagodi sharpens a point Zuber also raised: “Oftentimes there is lack of appreciation for the cost of continuous R&D and maintaining edge in a domain. Buying makes sense when this is not a core competency of yours.”

What’s striking across these responses is what no leader mentioned: cost. Neither talked about headcount or how fast they could ship. The conversation moved up a layer. Zuber asked what you want to own long-term, and both Mamut and Malagodi asked what’s part of your core product. All are saying the same thing in different vocabularies: the build-vs-buy choice is about the shape of your company, not the shape of the project.

That framing is exactly what the SaaSpocalypse narrative gets wrong.

The SaaSpocalypse is a market signal, not a fact

Something real happened in early 2026. Per-seat pricing took a beating it deserved. Horizontal tools whose only differentiation was a marginally better interface got repriced fast. Investors finally stopped paying a premium for subscription revenue that AI agents can route around. All of that is healthy market behavior.

What didn’t happen is the death of enterprise software. SaaStr’s Jason Lemkin pointed out the inconvenient detail: “enterprise software spend is accelerating in 2026 at the highest absolute rate ever recorded.” Gartner now projects worldwide software spend will hit $1.44 trillion in 2026, up 15.1% year-over-year, the third upward revision in six months. The buyers signaling the loudest concern about AI displacement are the same buyers writing the biggest checks for enterprise software that they expect will still be running in 2030.

The signal is that interface-only moats are dead. The fact is that systems of record, compliance infrastructure, and accumulated domain logic are not.

Agents need somewhere to read from and write to

The argument that AI agents make SaaS obsolete treats enterprise software like it’s a tool that performs tasks. Most of it isn’t. Most enterprise software is the digital encoding of how an organization actually works: who approves what, which fields do we require for compliance, how a deal moves from stage to stage, what happens when a customer churns, and who gets paged when something breaks. That’s institutional architecture, not a UI.

An agent that drafts a contract still needs the CRM to know which contract template applies to which customer segment. An agent that triages a support ticket still needs the ticketing system to route, escalate, and audit. An agent that closes the books still needs the ERP to know what was actually purchased, by whom, and against which budget. Strip the system of record out, and the agent has nothing to read from and nowhere to write to. It becomes a goldfish with a great vocabulary.

When a team spins up its own tooling with an agent in a few days, what they ship is a working surface without the scaffolding underneath. It lacks shared definitions, an audit trail when leadership asks how something changed, and continuity when the person who prompted the original build moves to another role. Six months later, three different teams are running three different versions of the same workflow, and nobody can reconcile them because the institutional knowledge that lives in a real system of record was never encoded. The agent shipped the feature, but it didn’t ship the organizational agreement that the feature was supposed to enforce.

The moat didn’t disappear; it moved

The SaaSpocalypse panic assumes that all SaaS moats are the same and that they are all dissolving. They aren’t. Here are a few ways SaaS companies have become even more defensible.

Compliance and trust infrastructure. SOC 2, HIPAA, FedRAMP, SOX, ISO 27001. Agents have to operate inside these regimes, not around them. The vendor that has already passed the audit becomes more valuable as more agents are in the building, because each agent inherits the trust posture of the system it acts through. Building your own version means inheriting your own audit burden, which is a cost most teams discover for the first time the day before their first security review.

Domain depth and proprietary data. A general agent can write code, draft a contract, or summarize a meeting, but it can’t tell you whether an unusual pattern in your operations is a genuine improvement or an emerging problem, or weigh years of institutional knowledge about what has and hasn’t worked against the pressures of the current quarter. The platforms that have spent years accumulating execution data across thousands of engineering organizations have something agents fundamentally need: ground truth. Bain’s research on agentic AI in enterprise software reaches the same conclusion: the durable moat in this era is accumulated execution data that grows more valuable over time and becomes harder for competitors to replicate. Agents consume data rather than replacing it.

Accountability. Agent-based systems need accountability, compliance, and trust, or they break down at scale. The systems you build around agents need to be reviewable, correctable, auditable, and explainable. The teams shipping the most successful AI deployments in 2026 aren’t the ones who ripped out their SaaS stack. They’re the ones who layered agents on top of SaaS systems mature enough to make agent behavior more consistent.

What you build, you forever maintain

Here’s where the build-everything thesis runs into the wall. LinearB’s analysis of 8.1 million pull requests across 4,800 teams found that AI-generated code waits 4.6 times longer for review than human-written code, and that AI-generated code is twice as likely to be reverted substantially or rewritten within 30 to 90 days. One MIT researcher described AI coding tools as “a brand new credit card that will allow us to accumulate technical debt in ways we were never able to do before.” The compounding is the point. Year one teams ship faster and feel productive. Eventually, you hit the wall when your maintenance burden skyrockets, velocity crashes, and paying down debt becomes the primary activity instead of feature development.

This is the part the SaaSpocalypse thesis ignores. The argument assumes the build cost is the primary cost, but it isn’t. The build cost is the deposit, and the maintenance cost is the mortgage. The teams that vibe-coded their way out of a few SaaS subscriptions in 2026 will eventually inherit exactly what Zuber warned about: software they don’t want to own, didn’t differentiate with, and now have to keep running.

The maintenance decision is made every day by people who might not have been part of the original decision, with less context than the original team had, against systems built fast and documented thin. SaaS vendors, for all their failures, absorb that work as part of what you pay them for. The build path doesn’t make that work disappear; it transfers it onto your team’s backlog, permanently.

Build to learn, buy to scale

Here’s the actual playbook for the post-SaaSpocalypse era. AI didn’t make every build decision easy. It made the cheap part cheaper and left the expensive part untouched. Ownership is the primary expense: the compliance, on-call rotation, integrations that break when things change, institutional knowledge that walks out the door when someone takes a new job, and the audit trail nobody thinks about until they need it.

What AI changed is that you can now afford to build the smallest thing that teaches you what the real problem is. The build is where you learn, the purchase decision is where you commit. The teams that confuse the two end up either over-buying tools they don’t understand or over-building tools they don’t want to own.

The companies that figure this out fast look like Wayfound: small, focused, building only what they can uniquely provide, and buying everything else with explicit intent. Or like CircleCI under Zuber: a platform mature enough to know exactly which infrastructure to own and which to delegate. Or like Sonar under Malagodi: clear enough on what they uniquely deliver to recognize when a specialist has already solved the adjacent problem better.

The SaaSpocalypse narrative says the answer is to build more, but the evidence says the answer is to build smarter. Use AI to learn the problem cheaply, then make the ownership decision deliberately. Some things you should own forever, but most things you shouldn’t. The build decision gets made once, and the maintenance decision gets made every day.

At LinearB, we wanted to pressure-test this for ourselves, so we ran an experiment. We pointed an AI agent orchestrator at LinearB and asked it to build an engineering productivity platform from scratch. Check out the on-demand workshop to see what we learned about the actual cost of ownership of the DIY approach.