The Build-vs-Buy Decision Needs a New Business Case

For years, the advice on building versus buying business software has been pretty consistent. If something already exists in the market, you're probably better off buying it. And for a long time, that made sense.

Building custom software took a real commitment. You needed developers, architects, designers, and people who understood the business well enough to define what the application should do, and even a relatively simple internal application could take months to deliver. Buying was sometimes the faster, lower-risk path, so the conversation usually started with what was available to purchase.

Agentic software development is starting to shift that. As coding agents take on more of the implementation, testing, and integration work, engineering teams can put more of their attention on understanding the business, making design decisions, and reviewing what gets built. That makes a focused application a realistic option in more situations. But I don't think what it takes to build is the right first question anymore. The better question is whether the company is ready to own what it builds.

Building Changed Faster Than Owning Did

McKinsey's August 2026 State of AI survey found that 32% of respondents said their organizations had decided against purchasing at least one software product or feature because they could build the functionality internally using agentic coding tools. Among the companies McKinsey classifies as AI high performers, the share was closer to half. Businesses are clearly already reconsidering where buying makes sense.

That doesn't tell us whether those decisions ultimately saved money, and I think the answer depends on something the old build-versus-buy math rarely put up front. When you build, you take on responsibility the vendor used to carry. Someone needs to maintain the application, manage integrations, address security issues, and make changes as the business evolves.

Agentic development can help with that ongoing work too. The same shift that changes how an application gets built can change how it gets enhanced and maintained, depending on the application and the team supporting it. But I don't think ownership has changed as much as delivery has. Agents take on more of the code, and the team's focus moves to deciding what to change, reviewing the work, and keeping the application secure and connected to everything around it. That work continues for as long as the application is in use, and it still takes people who understand the system. That's why I'd put ownership at the center of the business case rather than at the end of it.

Buying Was Never Free to Own Either

When you purchase commercial software, you're paying a vendor to develop and maintain the product. You're also depending on its roadmap, support model, pricing, and decisions about how the software should work.

Companies often end up purchasing considerably more functionality than they need. A team has a specific problem. They find a product that addresses it, but it's part of a larger platform designed for a much broader market. That can be useful if the business eventually needs those capabilities. It can also mean paying for a lot of software nobody uses.

Then there's the work required to make the product fit. Maybe the company's terminology doesn't match the application's data model. Maybe employees have to follow extra steps because that's how the product was designed. Or perhaps they need to move between three different systems to complete what should be a simple task.

Over time, those compromises become normal. Employees learn the workarounds. Administrators maintain the configuration. The company keeps paying for the subscription because replacing the application would be another expensive project. That last assumption is the one I'd question.

Licensing is only part of it. Configuration, administration, integration support, vendor-driven upgrades, and the work employees perform outside the system all have costs. Those belong in the business case just as much as the cost of supporting a custom application, and I'd compare both over several years rather than one.

The Easiest Software to Own Is Focused

Consider an insurance company that needs a better way for claims adjusters to manage supporting documentation. The insurer already has a core claims management system, but adjusters still spend time moving between applications to review documents, request missing information, and track outstanding items.

There are commercial products that could help. The company could evaluate vendors, purchase another subscription, configure the software, and integrate it with the existing claims platform. But what if the business only needs a handful of capabilities from a much larger product? Or the implementation requires enough customization that it starts looking like a development project anyway?

The insurer could instead build an application around its existing claims system, giving adjusters a better way to manage documentation without replacing the platform that handles the claims themselves. The claims platform stays the vendor's responsibility, and the new application is small enough that the company can realistically own it.

The same logic applies to a company with field technicians who rely on several applications throughout the day. One contains customer information, another manages equipment, and a third tracks service activity. Each system might work perfectly well on its own. The problem is everything employees have to do between them. A focused application that brings the necessary information together would leave each system managing its own data while giving technicians a better way to work across them.

There are still good reasons to purchase software. I wouldn't be particularly interested in rebuilding a mature payroll platform simply because coding agents could help generate the application. There's an enormous amount of functionality, regulatory knowledge, and ongoing support behind a product like that, and most companies have no interest in owning any of it.

Old Estimates Only Priced the Build

I'd be interested in revisiting the applications companies decided not to build. Most organizations have some version of that backlog.

Maybe someone proposed replacing a spreadsheet-based process with a dedicated application. The idea made sense, but the development estimate was too high. Or a department wanted a better way to work with information spread across several enterprise systems. Everyone agreed the experience was frustrating, but building something new couldn't compete with other priorities.

Those decisions were made using the delivery costs and capabilities available at the time. If the original estimate assumed several months of conventional development, I'd want to know what that same project looks like with an experienced team using coding agents. I'd also want the new estimate to include what the old one usually left out: who maintains the application, how it gets supported, and what it costs to keep running.

Think about how many small software problems an enterprise accumulates over time. Individually, they don't justify a major investment. Collectively, they can create a surprising amount of cost through licensing, manual work, and lost productivity. Some of those problems may now be worth building, and realistic to own.

Questions Worth Asking Before You Build

I don't expect companies to start replacing all their major enterprise platforms with applications built by coding agents. What I do expect is more attention to the smaller departmental applications, specialized tools, heavily customized products that still don't quite fit, and manual processes that have been waiting years for someone to justify building something better.

I'd start with a few questions. What does the business actually need? How much of the purchased product is it using? What's the current solution costing once licensing, administration, and workarounds are included? And who's going to own a focused alternative once it's delivered, and are they ready to?

Those are questions we should've been asking all along. What's different now is that the answers may have changed.

I'd be surprised if every build-versus-buy decision made five years ago still came out the same way today. I'd want to find out which ones don't.