Does AI Actually Make Building Your Own Tools Cheaper Than Buying?

The views expressed here are solely my own. They do not represent the opinions, positions, or policies of any current or former employer, client, or affiliated organization.

Here's the hypothesis: even with AI doing a lot of the coding, building your own tools rarely comes out cheaper than buying, once you honestly count the time it takes to test, adjust, and rebuild. I'm not theorizing from the outside. I've built several internal tools myself, small in scope, single-decision-maker, about as low-complexity as this gets, and I still spend real hours on it. If I priced my own time the way a company prices an engineer's, I suspect I passed the cost of a SaaS subscription a long time ago, for more than one of these tools.

So I checked what the research actually says, both the pre-AI literature on build vs. buy, and the newer data specifically on whether AI changes the calculation.

This isn't a new problem AI walked into. Software engineering has known for decades that the sticker price of building something is the smaller number.

Gartner estimates organizations spend 55-80% of their IT budgets maintaining systems they already built, not building new ones. Forrester's Total Economic Impact model puts it more precisely: roughly 78% of a piece of software's lifetime cost accrues after launch. The O'Reilly "60/60 rule," cited across IEEE software engineering literature, lands in the same range, maintenance eating 60% or more of total lifecycle cost, sometimes reaching 80% for long-lived systems. One frequently cited rule of thumb: maintenance ends up costing two to four times the original build over the software's life.

None of that has anything to do with AI. It's just what happens when you own something instead of renting it. The build is a moment. The maintenance is the rest of its life.

This is where I expected to find the counter-evidence, and mostly didn't.

METR, a nonprofit AI evaluation group, ran a randomized controlled trial in early 2025 with experienced open-source developers, the closest thing this space has to a rigorous study rather than a vendor claim. Developers predicted AI tools would cut their task completion time by 24%. After finishing, they estimated they'd actually been about 20% faster. The measured result: they were 19% slower with AI than without it. The gap between what developers felt and what the clock recorded was the headline finding, not the speed itself.

To be fair to the technology, METR reran a similar analysis in early 2026 and found the trend had flipped, an estimated 18% speedup, as developers learned to use the tools better and the tools themselves improved. McKinsey's separate research across roughly 4,500 developers found something similar in shape: meaningful time savings, around 46%, on routine, well-scoped tasks, but under 10% on genuinely complex work. So the story isn't "AI never helps." It's "AI helps unevenly, and the size of the help depends heavily on the type of work and how experienced you are with the tool," which is a much narrower claim than "AI makes building software cheap."

There's also a quality tax that rarely makes it into the pitch. Research tracking AI-generated code has found notably higher rates of security vulnerabilities and code issues compared to human-written code, alongside a near-doubling of code churn since 2020. That's not a one-time cost. Every one of those issues becomes a future maintenance hour, the exact category of spend that was already 60-80% of the total before AI entered the picture.

Put those two findings together and my hypothesis holds up. Even in the most generous reading, current data, AI speeds up parts of the build phase for some kinds of work. It says nothing about the maintenance phase, which was always the larger cost, and there's early evidence it may add to that phase rather than shrink it, by introducing more defects to fix later. If maintenance was 60-80% of the bill before, and the build phase gets faster while the maintenance phase possibly gets more expensive, the total cost doesn't obviously move in the direction the "AI makes building free" narrative implies.

Here's the part that matters for people in my position specifically, not as an exception that saves the hypothesis, but as the boundary condition every serious build-vs-buy framework already names. The standard advice, unchanged by AI, is that building makes sense when the software is the actual differentiator and you need customization no vendor offers.

That's the case for the tools I'm building. The Signal, Sir Balone's Scout app, the Content Studio, none of these are generic CRMs or project trackers I could swap for a subscription. They're built around methodology and data that don't exist as a purchasable product, because the thing being encoded is my own analysis framework, not a workflow a vendor already generalized for a market. There is no SaaS to buy in that case, so the comparison isn't build vs. buy, it's build vs. don't have it.

The other honest variable is what my time is actually worth in this specific window. I have time and no tool budget right now. That's a real, if temporary, condition, not a permanent economic law. If I were pricing my hours the way a company prices a loaded engineer, several of these projects would already have crossed the break-even point against a subscription. The reason it still works for me isn't that AI made building cheap. It's that the alternative use of those specific hours, right now, isn't billable client work I'm giving up.

As a general claim about companies with budgets and alternatives, yes, I think it holds, and the literature backs it more than it contradicts it. The 55-80% maintenance-cost reality predates AI and doesn't disappear because the first version got written faster. The one legitimate exception, proprietary IP with no market equivalent, isn't really an exception to the rule. It's the one condition every framework already says justifies building, AI or not.

What I couldn't find, anywhere, was a study showing that AI has changed the total lifecycle math enough to flip build-vs-buy into "build, generally." What I found was evidence that AI changes how fast the first draft gets written, and mixed-to-concerning evidence about what that first draft then costs to keep alive.

Juan Carlos Vásquez has spent ten years inside enterprise content operations, repairing content supply chains before scaling them. Fix to Flow is the discipline that work produced. The views here are his own.