AI has dramatically reduced the cost of building software. But building software and owning it are two very different things. That gap decides whether open source and AI-built tools can replace the SaaS platforms organizations pay for today.

The current debate goes like this. AI agents are becoming the front end. They call APIs and Model Context Protocol (MCP) servers directly, so the screens, workflows, and per-seat licenses that made SaaS valuable start to matter less. Meanwhile, AI coding tools let a small team build in weeks what used to take a vendor years. If you can build a solution tailored to your business faster and for less money, why keep paying for an off-the-shelf platform?

It's a fair question. I've watched the industry ask a version of it before, and how that played out is the best guide I know to what happens now.

We have made this choice before

Earlier in my career, including my years at Cisco, I watched private cloud teams weigh VMware against OpenStack, and network teams debate traditional vendor gear versus white-box switches. On paper, the open options offered lower costs and greater flexibility. Yet most enterprises continued paying for proprietary platforms. And for a good reason.

OpenStack was free to download, but far from free to run. It required skilled platform engineers to integrate, upgrade, and support it. Most enterprises didn’t have those resources in-house, and the savings on licensing often disappeared into labor costs, operational complexity, and downtime.

White-box networking followed a similar path. Hyperscalers with deep operations benches adopted it at scale. Most enterprises stuck with their established vendors, not necessarily because the technology was better, but because they valued the support and accountability that came with it.

Here's what I think gets overlooked. Open source did not lose that battle. It won. Linux, Postgres, Kubernetes, and Kafka now run most of the world's infrastructure. But rather than managing everything themselves, most enterprises choose to consume these technologies through managed services, with cloud providers or vendors taking responsibility for keeping them running.

The deciding factor was never simply open source versus proprietary software. It was who could absorb the operational risk, and at what cost.

What AI and headless agents actually change

That history matters, but I think four things are genuinely different this time.

First, it's worth explaining what we mean by headless agents. Unlike traditional software that relies on people clicking through screens and navigating menus, headless AI agents operate behind the scenes. They interact directly with applications, data, and other systems through APIs and integrations, often without a traditional user interface.

Think about an employee who needs to pull information from three different platforms, update a record, and generate a report. Today, that might mean logging into multiple applications and moving between screens. A headless agent can potentially handle that workflow by connecting directly to those systems, without ever opening the applications the way a person would.

That's a meaningful shift, and it changes the economics of enterprise software in several ways.

1. The interface is commoditizing. Much of SaaS value lived in the screens and workflows people used every day. When an agent becomes the user, it works through APIs and the MCP, the emerging standard for connecting agents to tools and data. It never sees the screen. Per-seat pricing is exposed when the seats are agents.
2. Build cost has collapsed for narrow tools. A competent team with AI coding tools can now build an internal app, a reporting layer, or a workflow tool in a fraction of the old time. The build-versus-buy math for point solutions has changed.
3. Integration is cheaper. Glue code between systems used to be the most brittle, expensive part of any stack. Agents and generated code handle more of it. That lowers switching costs.
4. Open models and open tooling are viable. Teams can assemble capable stacks from open components without a platform vendor in the middle.

Taken together, these changes challenge some of the assumptions that have supported the SaaS business model for decades. A meaningful portion of what enterprises currently pay for can now be built or replaced more easily.

But that doesn't mean replacing it is always the right decision.

What does not change

Building is the short part of a business system's life. The rest is running it. That part moved far less.

Agents make some of this easier, but they don't eliminate the underlying responsibility. At the end of the day, someone still owns the outage, the audit finding, or the breach.

Systems of record are the clearest example of where this distinction matters. ERP platforms, core customer data, billing systems, and regulated workloads aren't valuable simply because of their interfaces. Their value comes from the integration of the data, the audit trail, and accountability behind them. Agents make those systems more valuable, not less. After all, an agent is only as reliable as the information it uses and the systems it acts on.

My read? The SaaS vendors most at risk are not the ones managing your critical data. They are the ones whose primary value has been giving people a way to interact with it.

The new debt: AI-generated legacy

AI produces code faster than organizations can produce people who understand it. That creates a new kind of technical debt.

Consider a department that replaces three SaaS tools with custom applications built over a few weekends. Initially, everything works. The business saves money, the team moves faster, and it looks like a win.

Then the engineer who built them moves on. Suddenly, the organization is left with three applications that nobody fully understands, nobody thoroughly reviewed, and nobody is prepared to support when something breaks at 2 a.m. Dependencies become outdated. Access controls drift. And when someone asks what data these applications can access, there's no clear answer.

I haven't seen this happen at scale yet, but I've seen enough in technology to recognize the pattern. It's the OpenStack failure mode at smaller scale and much higher volume. The consequences won't necessarily show up on day one. They'll surface during the first audit, the first security breach, or the first time a regulator asks who authorized a change.

I'm not arguing against building your own software. I'm arguing against building it without a plan to own, secure, and maintain it long after the initial excitement wears off.

The operating and ownership models change the risk equation

Replacing a SaaS platform may change the contractual protections available when something goes wrong. Part of the value of engaging a third party may come from contractual commitments, including service levels, indemnification, security obligations, and remedies when those commitments aren't met.

Security is one of the clearest examples. Organizations may remain responsible to customers and regulators for protecting personal and regulated data regardless of who operates their technology. But an agreement with a technology provider can establish responsibility for specific safeguards, incident response, and certain losses, subject to the terms and limitations of that agreement. Bringing those functions entirely in-house may mean assuming more of those responsibilities and costs directly.

The same distinction matters when it comes to commitments made to customers. Replacing a SaaS platform doesn't necessarily change the service levels, security standards, or other contractual obligations an organization has agreed to meet. If the replacement fails to meet those commitments, the organization may remain liable to its customers. Its ability to recover those losses from a technology provider, however, depends on the protections and limitations in the applicable agreement.

Before making the decision, compare the obligations you owe customers and regulators with the contractual protections available under the proposed arrangement. Pay particular attention to liability caps, exclusions, indemnification, and available remedies. The costs of risks that remain with the organization belong in the financial analysis, just as much as development and operating expenses.

But what do you actually own?

Deploying a headless agent doesn't necessarily mean owning the technology behind it. Likewise, paying to develop a custom solution doesn't necessarily mean acquiring all the intellectual property rights in it.

The first step is distinguishing what you're buying or building from the technology used to create or operate it. Is the agent running on a third-party platform, or is it custom-developed? If it's custom-developed, do you actually have access to the source code? Who owns the underlying code? What rights do you have to use, modify, and maintain it? The agreements should distinguish customer-specific deliverables, the developer's preexisting intellectual property, and third-party technology.

Even a contract that clearly assigns intellectual property rights cannot create copyright protection where none exists. In 2025, a federal appeals court held that the Copyright Act requires human authorship, affirming the denial of copyright registration for a work whose sole identified author was an AI system. The Supreme Court declined to review that decision in 2026, leaving the ruling in place. AI-assisted work can still qualify for copyright protection when there is sufficient human creative contribution, but that's an important distinction as companies increasingly rely on AI-generated code. That distinction matters particularly when an organization expects exclusive rights to the software it has developed, rather than simply the ability to use it.

Third-party components introduce another consideration. AI-assisted development can also introduce open-source components. Depending on the licenses and how those components are incorporated, used, or distributed, their terms may impose obligations affecting other parts of the software, including requirements to make source code available to others.

The AI development platform's terms introduce another layer of consideration. Who owns the output? Can the platform use your company's intellectual property to train its models?

The goal isn't necessarily to own every component or eliminate third-party relationships. It's to make sure the organization has the legal rights it needs to use the solution as intended, understands the rights retained by others, and has the flexibility to support its long-term business needs.

Replace, wrap, or keep

Two questions sort most of a SaaS portfolio:

1. Where does the value live, in the interface or in the data?
2. Can your organization operate what it builds?

Replace what you can. Wrap or keep what holds your data.

Use those two questions to evaluate every renewal. The answer won't always be straightforward, and it doesn't have to be all or nothing. Most organizations will find that the right approach is a mix of both.

What engineers should do differently

This section is for the people on my side of the table: engineers and architects. Your customers are already questioning what they should build, buy, or replace. Whether you bring it up or not, these conversations are happening. Our job is to help them think beyond what's technically possible and understand what they can realistically support.

• Qualify on operating capacity, not feature fit. Before recommending a solution, ask who will maintain, monitor, secure, and support it. If the answer is "the team that built it," the next question should be what happens when that team moves on.
• Separate the interface from the data. Show the customer which part of their spend pays for screens and which part pays for an authoritative system. Only the first is truly at risk.
• Price the whole life, not the build. A build-versus-buy comparison that stops at go-live is incomplete. Include run cost, staffing, compliance, and exit.
• Expect agent access in every deal. Customers will ask whether a platform exposes clean APIs and an MCP server for agents, and how those connections are authenticated and audited. A product that only works through its own screens is a harder sell than it was a year ago.
• Don't defend the platform by reflex. Sometimes replacing a tool really is the better decision. We should be willing to say that. But we also need to help customers understand what comes next, including who will own and operate whatever replaces it. That's how we move from simply recommending technology to becoming trusted advisors.
  
  

How we approach it at TSG

The last technology cycle was won by whoever made open technology reliable, secure, and practical to operate at scale. I expect this cycle to follow a similar path.

That view shapes how we work with customers at The Select Group (TSG). We don't have a proprietary platform to push or protect. Our focus is on helping customers make the right decisions for their business, whether that means replacing an existing tool, extending its value, or keeping it exactly where it is.

In practice, it looks like this:

• Start with the right questions.  Run a short discovery focused on part of the customer's technology portfolio to understand what makes sense to replace, extend, or keep. 
• Prove the approach before scaling. A bounded replacement or wrap, with monitoring, patching, access control, and audit evidence designed in before go-live.
• Measure against an agreed baseline. The customer sets the measures up front. Then they decide whether to expand, adjust, or stop.
• Stay for the run. Depending on the customer's needs, we can help operate and maintain what we've built, embed engineers within their teams, or transition ownership through documentation, knowledge transfer, and a structured handoff.

And we're equally clear about accountability. We don't promise outcomes that depend on factors outside our control, whether that's user adoption or a third-party vendor's roadmap. We define what we're responsible for, what the customer owns, and what success looks like for both.

Sources and further reading

Each source below backs a specific claim in the article. Vendor research is marked so readers can weigh it.