To SaaS or Not to SaaS? Rethinking Software in an Agentic World

For the last decade, SaaS has been the default answer to almost every business problem. Need a CRM? SaaS. Marketing analytics? SaaS. Internal tooling? Definitely SaaS. The pitch has always been compelling: don’t build, just buy. Move fast. Let someone else maintain the infrastructure.

But as we move into a more agentic AI driven future, it’s worth asking a slightly uncomfortable question: is SaaS still the right abstraction for every business?

Or are we about to see a shift where more companies quietly build their own tools again? Not monolithic on prem software like the old days, but lightweight, highly tailored UIs and workflows that sit on top of APIs, data warehouses and LLMs.

In other words: less SaaS consumption, more software composition. APIs and MCPs have changed the economics.

One of the reasons SaaS won so decisively was cost and complexity. Building internal tools used to be slow, expensive and brittle. Today, that equation looks very different.

Most core platforms, CRMs, ad platforms, analytics tools and payment processors now expose mature APIs. Google Ads, Meta, Shopify, Stripe, even many data warehouses are explicitly designed to be programmatically controlled. In many cases, the UI you log into is just one possible interface over an API first system.

That means businesses can increasingly ask: why am I paying for a UI that doesn’t reflect how my team actually works?

Instead of forcing workflows through someone else’s product decisions, teams can buy or build a thin UI layer, pull in exactly the data they need, and orchestrate it through agentic tools that reflect their internal processes. Not replacing the underlying platforms, but replacing the way humans interact with them.

The SaaS ceiling problem

Of course, not all SaaS vendors are equal here.

Platforms like ad networks or infrastructure providers are generally happy to expose deep APIs because their value isn’t the UI, it’s the ecosystem, data gravity or network effects.

But many high margin SaaS products sit in a more awkward middle ground.

CRMs and analytics tools are a good example. Products like Salesforce or HubSpot provide real value, but their APIs are often deliberately scoped. You can read data, sometimes write data, but you can’t fully replicate or recompose the service. That’s not accidental – it’s how they protect their moat.

The result is that customers end up paying for increasingly bloated interfaces, features they don’t need, and rigid workflows simply because the alternative, rebuilding, used to be unrealistic. However, that assumption is starting to weaken.

Agentic tools change expectations

Once you introduce LLMs and agents into the mix, the limitations of traditional SaaS become more obvious.

Agents don’t want dashboards. They want structured access to data and actions. They want predictable APIs, clear schemas, and the ability to chain decisions across systems.

Humans, meanwhile, want interfaces that explain decisions, not just report metrics.

When you build in house, you can design UX specifically for this human/agent collaboration. You can decide what gets surfaced, what stays abstracted, and how context flows between systems. SaaS tools, by necessity, design for the average customer, not your specific operating model.

The data security angle most people miss

There’s another dimension to this conversation that doesn’t get enough attention: data security in an AI first world.

As soon as LLMs are involved, data leakage and training risk become real strategic concerns. Even if vendors promise isolation, you’re still constrained by their architecture and assumptions.

If you control your own agent layer, you can do things SaaS platforms simply can’t accommodate. You can obfuscate sensitive fields before they ever touch an LLM, while still preserving semantic meaning. You can control prompts, embeddings, logging and retention.

You can make it deliberately hard for stolen data to be useful for model training without degrading output quality. That kind of control is almost impossible when you’re piping data into a third party SaaS that expects information in a very specific format.

You can’t realistically ask Salesforce to redesign their system prompts or accept obfuscated schemas just for you.

In house you don’t have that problem. You own the interface between data and intelligence.

This isn’t 'SaaS is dead'

To be clear, this isn’t an argument that SaaS is going away. Far from it. Foundational platforms, infrastructure tools and commoditised services will remain SaaS heavy.

What’s changing is where differentiation lives.

For many businesses, the competitive edge won’t come from which SaaS tools they subscribe to, but from how they compose, control and interface with data across those tools. That pushes value up the stack, away from generic dashboards and towards bespoke agentic layers.

In that world, “build vs buy” becomes a false dichotomy. The real question is: what should we own?