When I talk to engineering leaders about how their team decides whether to build a piece of software instead of buying something off the shelf, the decision usually starts at, “well, can we?” For most of the last decade, that was a reasonable first question, because unless the team had a quarter’s worth of runway and a specialist to spare, the answer was “no.” But now, AI has made the answer “yes,” at least on the surface. Any competent team can prototype projects like a working test framework, a monitoring dashboard, or an API harness, over a long weekend. The question is no longer “can we build it?” Rather, teams are asking “should we?”  

And that distinction is what most of the “build vs. buy” conversations miss. 

I’ve spent a lot of this year listening to how customers approach this decision and keep hearing the same themes around building:  

• It’ll be cheaper.  

• An AI subscription already cleared the budget, so the marginal cost is zero.  

• An old framework still works with a few customizations. 

• The backend is too complicated for an off-the-shelf tool to fit without months of custom integration.  

• Compliance won’t allow a third party to access the data. 

Everyone of these sounds reasonable on day one. The challenges show up later. 

The free option that never stays free 

Recently, I spoke with a team that found a capable open-source framework that met their needs and concluded that buying made no sense. In that moment, they were right. In their case, it was Apache JMeter, and indeed it will run a serious load test as any off-the-shelf solution. Similarly, Bruno lets a developer fire off API requests without a cloud account or a per-seat invoice. However, neither is built at scale for the access control, audit trails, and scheduled monitoring an enterprise eventually needs. 

What the team didn’t consider in their cost assessment is what happens three or six months down the road. In this case, JMeter’s plugin drifted out of step with its own release cycle until a routine upgrade broke their test plan. Similarly, Bruno is built for individual developers working alone, so it’s only once a team scales its usage that it discovers there is no access control, no audit log, and no scheduled monitoring. 

A second version of this illusion is becoming even more common: a Claude or Copilot subscription that already cleared procurement making the “build” decision look like it carries zero marginal cost, like open source.  Only after building and scaling does the team realize the maintenance and upkeep necessary to use the tool successfully and keep it working as intended.  

The calculus behind build vs. buy hasn’t changed as much as the headlines suggest. Barry Boehm’s original software cost estimation research established decades ago, and subsequent industry analysis, including work from the IEEE Computer Society, keeps confirming it: maintenance runs 50 to 80% of a system’s total lifecycle cost. AI didn’t change that math. All it changed is how convincing the first 30 days look before the math arrives. 

Finding the real advantage in building 

Your developers are paid to build competitive products in your own market, and this is where you can find the cost that rarely makes it into the original business case. The maintenance burden of internally developed tools gets absorbed unknowingly into your engineering team, where they compete with your roadmap for the same capacity.  

What AI did is change two things: first, how quickly teams can convince themselves that building is the right decision. A working prototype used to take a quarter, which gave someone time to ask what it would cost to keep running. Now the demo shows up on Monday, and the team makes the call before anyone asks. Second, AI levelled the playing field for generating code; every serious player can do that now. What it didn’t level is knowing whether that code works as intended. The competitive advantage no longer lives in the build vs. buy decision. It lives in the context AI tools can use to make workflows more complete or offerings more compelling. 

Building is sometimes the right call. For example, if the tool is a low-stakes utility that only a small workgroup will ever use, building can make sense. When it breaks, you lose an afternoon and it has little impact. The other case for building is on the other side of the spectrum: when the intellectual property and historical context are so rich that it creates a competitive advantage, this is justification for building on your own unique capabilities. However, increasingly, AI is masking the fact that most build decisions don’t fall into one of those two categories.  

Build vs. buy is an old debate. On the face of it, AI has changed the economics. The reality is that the cost is still what it always was: your team’s attention to your own competitive offering. If you’d like to talk to us more on this, here’s how you can get started.