Blog

2/3 of SaaS companies will not survive the AI era

The 2/3 SaaS survival claim matters because AI is making narrow application software easier to rebuild, while trusted infrastructure, hard-to-recreate systems, and real workflow context remain more defensible.

2/3 of SaaS companies will not survive the AI era

2/3 of SaaS companies will not survive the AI era is a dramatic claim, but it points at a useful operating question for buyers: which software still deserves to exist as a full product, and which software only survives because nobody has redrawn the workflow boundary yet?

Business Insider's report on analyst Pat Walravens's SaaS outlook frames the shift clearly. AI is making software easier to build and easier to replace, which puts more pressure on application-layer SaaS than on the infrastructure and system layers underneath it.

That does not mean the end of SaaS arrives all at once. It means the future of SaaS becomes more selective. Broad software suites that still hold trusted records, hard-to-recreate complexity, or real operational infrastructure may stay durable. Narrow application surfaces that only wrap one repeated workflow look much easier to squeeze.

If you want the broader market-pain definition first, start with What is SaaS sprawl?. This article is about why AI replacing SaaS is no longer only a theory for investors. It is now a workflow and buying problem for operators.

What “will not survive” usually means

The dramatic line is easy to misread.

Walravens's point is not that two-thirds of SaaS companies all go bankrupt at once. It is that many of them may get acquired, rolled into broader platforms, or lose relevance the same way earlier software leaders lost ground in the move to cloud software.

That matters because software sprawl is often the operating trace of that same shift. Teams keep renting broad products for narrower jobs, even after the old product shape stops making sense.

The split that matters: infrastructure versus applications

The Business Insider piece draws a useful line between infrastructure and applications.

Infrastructure vendors tend to sit closer to the underlying systems other tools depend on: communications rails, data layers, delivery channels, and other surfaces that AI still needs to reach the real world.

That is why the article points to companies such as Twilio and Bandwidth more favorably. If AI increases the amount of software being generated and orchestrated, the underlying infrastructure can become more important rather than less.

Application software faces a harder test.

Products that mainly package task tracking, approvals, internal ticket handling, project coordination, or other narrow operational jobs are more exposed when teams can now build a decent, smaller replacement around the exact workflow they still need.

Why this is really a SaaS sprawl story

This is where the “AI replacing SaaS” conversation becomes more than noisy market commentary.

SaaS sprawl grows when a company keeps paying for more product than the workflow actually needs. AI changes the economics of that mismatch.

What used to require another suite, another module, or another renewal cycle can increasingly be handled by a narrower custom workflow, a smaller internal tool, or a focused automation surface wrapped around the existing record.

That is why AI agents vs SaaS is not a pure technology debate. It is a workflow ownership debate.

The buyer's litmus test is simpler than the investor's

Investors care about revenue growth, pricing model durability, and market multiple expansion.

Operators need a simpler test.

Ask four questions:

  • Does this product hold a trusted system of record, or is it mostly a workflow wrapper?
  • Is the hard part the data, governance, and operational complexity, or just the interface and routing logic?
  • Could a decent version of this workflow be rebuilt as a smaller internal tool or custom workflow?
  • Are we paying seat-based SaaS prices for a job that now looks much narrower than the bundle around it?

The more uncomfortable those answers become, the more likely the team is looking at SaaS replacement pressure rather than durable software advantage.

What survives better in the AI era

The products that look safer usually have one or more of these properties:

  • they own sensitive or regulated records people are reluctant to move
  • they connect directly to real-world systems, transactions, or communication rails
  • they solve a workflow that is genuinely hard to recreate cleanly
  • they carry governance, reliability, and operational context that a quick build cannot replace

That is why the future of SaaS is unlikely to be “everything disappears.”

The more realistic outcome is that the weakest application layers get squeezed first, while harder infrastructure and trusted-record systems remain more defensible.

What gets squeezed first

The surfaces under the most pressure are usually the ones that already feel bloated.

That includes software bought for simple project coordination, lightweight approvals, basic request routing, internal admin queues, repetitive reporting, or other narrow jobs that no longer justify the full seat count and feature surface around them.

That is also why the end of SaaS, when people use the phrase loosely, often really means the end of some SaaS wrappers rather than the end of business systems altogether.

The software that only adds drag around the real workflow becomes much easier to question once AI and better internal tooling make custom workflows commercially credible.

What to do next

The safer response is usually to name the workflow precisely, keep the system of record intact, and stop carrying a bloated application layer around the edge of the job.

That is a more practical move than trying to replace every system at once.

If you want the broader problem framing, continue with What is SaaS sprawl?. If the pain is that one product has simply grown too large for one repeated job, continue with SaaS bloat. For the wider SaaS-sprawl category view, continue with SaaS Sprawl.

Keep reading

12 June 20263 min read

Nintex vs custom workflow

Nintex vs custom workflow becomes the real decision when the team only needs one narrow operating surface and must choose between another platform and a more deliberate workflow build.

Open article
Approval workflow: how to automate it
12 June 20267 min read

Approval workflow: how to automate it

Week one of the SwarmCraft case-study series turns a purchase approval workflow into a 32-ticket project board, five implementation packets, and a practical path away from manual approval chasing.

Open article
11 June 20263 min read

Pipefy replacement

A Pipefy replacement usually becomes relevant when the team wants to keep the useful workflow outcome, but no longer wants the full product surface around it.

Open article