The Build vs. Buy Equation Just Got Rewritten
Years ago, I got an email from our CTO that said:
“Remember, we always have to consider the build vs. buy decision.”
He meant it as gospel — a principle of responsible engineering. If you could buy it, you should. Building was for when you had to — when nothing off-the-shelf fit.
At the time, that was sound logic. Buying was predictable. Building was expensive, slow, and hard to maintain.
But in the last 8 months AI has shifted all the numbers in the spreadsheet.
The Old Math Is Broken
When we used to run the “build vs. buy” analysis, the costs were dominated by one thing: manual development effort.
Designing, coding, testing, and maintaining software consumed months of developer time. Even if you invested in building your own software team, they could never keep up with everything you wanted to build.
That’s why most companies defaulted to buying.
Recent releases of AI-assisted software development tools, such as Claude Code, have blown a hole in that logic. The act of writing and refactoring code — once the biggest cost line — has dropped by 80–90% in time to deliver (anecdotal in the past 2 months based on my experience and others I've talked to).
And the remaining parts of the cycle — planning, testing, maintenance — are now as much as 20–30% faster thanks to AI copilots, code analyzers, and context-aware assistants that can instantly summarize logic, suggest fixes, and generate documentation (Bain survey).
If you’ve been assuming “build” is 10x the cost of “buy,” it's time to revisit that assumption.
Building Now Creates a Strategic Asset
When you build today, you’re not just creating internal software. You’re creating an option.
Because the second-order effect of cheaper, faster custom development is this: When you build, you automatically open the door to sell.
Not every company wants to be in the software business. But the barrier to entry has collapsed.
If your team builds a tool that solves a real operational problem, and you can build it using your existing cash flow — you now own an asset that could become a product.
A few years ago, spinning off a SaaS product meant new funding, new hires, and massive infrastructure overhead. Now you can do it without making it a bet-the-company project.
That’s the hidden cost of ignoring this shift — you’re forgoing an entirely new business option. If your competitors are building with AI and you’re still buying, they’re not just getting to define the direction of their software — they’re developing the next generation of products they'll soon be licensing to you.
The Market Will Tilt
As AI-assisted development becomes the norm, two things will happen at once:
The number of custom builds will increase. Companies that would never have considered building five years ago now see it as viable.
The number of SaaS products will explode. Because every new build has the potential to become someone else’s “buy.”
It’s a feedback loop: the cheaper and faster it gets to build, the more buy options the market produces — but also, the more companies realize they could be the ones selling.
So as a CTO or CEO, the question isn’t just:
“Should we build or buy?”
It’s:
“Can our build become someone else's buy?”
The New Evaluation Rubric
The build vs. buy framework still applies — but the values in it have changed.
Build gives you control, differentiation, and now a potential path to monetize.
Buy is still faster, cheaper, and easier. But significantly less than it was last year.
Leaders who adjust their intuition first will gain an unfair advantage in the next wave of AI-driven efficiency.
If you’re actively revisiting your own build-vs-buy assumptions and want the clarity checklist we use with leadership teams to update their decision rubric, send me a direct message — happy to share it.
Sources:
Bain & Company, Scaling AI While Controlling Costs (2025).
