AI Is Changing the Build vs. Buy Conversation

AI has made building software dramatically easier — but it has not made owning software any easier. That distinction is quietly reshaping the enterprise build-versus-buy decision, and it matters far more than the headlines declaring that AI is about to kill SaaS.

Every few days another article argues that AI is the end of packaged software. The reasoning is familiar: AI can now generate sophisticated applications from a prompt, the cost of writing code is collapsing, and soon every company will simply build the tools it needs rather than license them from someone else. I agree that AI changes this conversation profoundly. I just don't think it changes it in the way most people assume.

What did build vs. buy actually used to be about?

For years, the build-versus-buy decision was framed as a cost-of-development question. If building meant a large engineering team, long delivery cycles, and heavy upfront investment, buying an existing platform usually made better economic sense. But development was never the whole cost. Building software also meant building product management, maintaining a backlog, and balancing competing demands from marketing, operations, finance, and IT. It meant managing technical debt, running infrastructure, responding to production incidents, planning upgrades, investing in security, keeping documentation current, and evolving the platform as the business and its customers changed.

In other words, choosing to build was never simply choosing to build an application.

You were choosing to become a software company.

How does AI actually change the equation?

AI changes that math dramatically, and organizations should take advantage of it. At Exchange Solutions, we've embraced AI across our engineering organization — helping developers move faster, explore more ideas, automate repetitive work, and spend more time on problems that actually matter. We've built internal applications that give us deeper visibility into cloud costs and operational waste, consolidated data from multiple operational systems into a single view for our IT operations team, and created new ways to work with platforms like Jira and GitHub. None of that required replacing the enterprise platforms we depend on. It extended them.

That is where I think AI creates some of its greatest value. Historically, organizations had two options: adapt your processes to fit the software, or build a replacement that better reflected how your business actually operates. AI introduces a compelling third path — keep the enterprise platform, but build intelligent capabilities around it that automate, integrate, and differentiate, without recreating everything the platform already does well. This is the essence of a composable, API-first approach, and it's why we built ES Engage™ to layer real-time intelligence onto systems retailers already run.

Why is "easier to build" not the same as "easier to own"?

Where we need to be careful is in assuming that because software has become easier to build, it has also become easier to own. Those are fundamentally different problems.

I was reminded of this recently while working with a customer on a significant enhancement to ES Loyalty™, our enterprise loyalty platform. The feature itself wasn't the discussion. What prompted the conversation was the increase in ongoing monthly operating fees required to support it. There was genuine surprise that adding a capability would also increase the cost of running the platform — the assumption being that since AI has made developers so much more productive, once a feature is built, the ongoing investment should be small.

I understand why that assumption is spreading. We can all watch AI generate applications, write code, produce tests, and accelerate development in ways that seemed impossible a few years ago. What's much harder to see is everything that happens after the code is deployed.

Why is the first release the easy part?

I've spent most of my career building enterprise marketing technology — from email marketing platforms early on to loyalty and customer engagement today. Loyalty is my example here, but the same pattern holds across payments, banking, healthcare, ERP, identity management, and countless other enterprise platforms.

AI can absolutely generate a loyalty application. It can produce member registration, points, rewards, promotions, APIs, and admin screens remarkably fast. Building the first version is no longer the hard part. The challenge begins after the first release.

Businesses evolve. New channels emerge. Regulations change. Marketing wants capabilities nobody anticipated. Partners are added, integrations multiply, teams turn over, and the original developers move on. Every one of those moments introduces another business rule, another edge case, another operational decision that has to be understood, tested, and supported for years. Over time, those decisions become the product. They represent accumulated operational experience — financial liability and partner settlement, transaction reversals, fraud prevention, audit requirements, and the lessons learned supporting real customers in production. They exist not because they looked elegant on a whiteboard, but because something happened in the real world that taught us they mattered.

What happens to organizations that choose to build?

Over the years we've worked with organizations that chose to build these capabilities themselves. Most of those decisions were entirely rational at the time — talented engineers, unique requirements, and a belief that owning the platform would deliver greater flexibility. Many of those projects succeeded initially. The first release met expectations, the business moved quickly, and everyone felt validated.

Years later, many found themselves somewhere very different. The platform had become harder to evolve. Every enhancement carried more risk. Every release required more coordination. Knowledge concentrated in a handful of people. What began as a software project had quietly become a business capability that required continuous investment simply to stay stable, secure, compliant, and relevant. The engineers were never the problem, and neither was the software. The organization had underestimated what it was choosing to own.

So what question should leadership teams actually ask?

I've come to believe the build-versus-buy discussion was never really about software. It's about deciding where your organization should invest its time, talent, and attention. AI changes the conversation because it dramatically lowers the barrier to building. Increasingly, the answer to "Can we build it?" will be yes. The more important question is whether building and operating that capability moves your business closer to the reason it exists.

If the software differentiates your business, creates a competitive advantage, or lets your teams operate in ways competitors can't easily replicate, then AI has never made it more attractive to build. But when the software represents years of accumulated operational expertise, continuous investment, regulatory accountability, security, support, and a commitment to keep evolving long after the original developers have gone, the decision becomes far larger than software development. You're no longer deciding whether to build an application. You're deciding whether your organization wants to own that capability — and everything that comes with it — for years.

Every organization exists for a reason. Retailers exist to serve customers. Manufacturers exist to build products. Financial institutions exist to manage financial relationships. Healthcare providers exist to care for patients. Software is now central to every industry, but very few organizations exist to build and operate enterprise software as their core business.

Is AI killing SaaS?

I don't think so. I think it's changing the build-versus-buy conversation in a much more fundamental way. AI should encourage organizations to build more software than ever — but that software should amplify what makes the business unique rather than distract it from its purpose. Sometimes the right decision is to build. Sometimes it's to extend the platforms you already rely on. And sometimes it's to partner with an organization whose entire business is owning that capability, so yours doesn't have to.

AI has made building software dramatically easier. It has not made becoming a software company dramatically easier. So before deciding to replace an enterprise platform, every leadership team should ask a much simpler question than "Can we build this?" — Is building and operating this capability part of the reason our business exists, or are we about to become a software company by accident?

Shane O'Neil

Chief Technology Officer, Exchange Solutions

Shane is a technology leader at the intersection of AI, SaaS, and enterprise loyalty, driving Exchange Solutions' shift toward AI-powered delivery across architecture, development, QA, operations, and product strategy. He has spent his career building enterprise marketing technology, from early email marketing platforms to loyalty and customer engagement today.

Connect with Shane on LinkedIn →