Build vs buy software in the age of AI: why the math has changed

Treefrog Consulting · 2026-11-10

The old math

Building your own software used to mean a team of ten, eighteen months, a budget that doubled, and a system that needed those ten people forever. Against that, a licence fee and a configuration project looked prudent even when the product fitted the business badly. So businesses bought, and bent themselves around what they bought: workarounds, spreadsheets, re-keying, and a process identical to every competitor on the same platform.

What changed

AI-accelerated engineering collapsed the cost of building. A senior engineer working with AI tooling drafts screens, data models and tests from a prototype in days rather than months; the engineer's time goes on design, review and the edge cases, not on typing. A system that took a year is built in a quarter by a team of two or three. Bespoke is no longer the expensive option. It is often the fast one.

At the same time, the cost of buying went up in ways that do not show on the invoice: per-seat fees that climb annually, a vendor roadmap you do not control, change requests queued behind a thousand other customers, and the strategic cost of running the same process as everyone else.

The new decision

Build when the workflow is your competitive edge, when off-the-shelf would meet seventy per cent of the need and force workarounds for the rest, or when you want to own the asset outright. Buy when the function is a commodity — email, accounting, HR — and the vendor's roadmap is good enough. Integrate when you already own a platform that does the core well but leaves gaps: wrap AI and bespoke modules around it rather than replace it. Most real answers are a mix.

Do the Living Requirements Document first

Whichever way you lean, do not decide until your users have clicked through a prototype. A Living Requirements Document — a working mock-up of the system with your data in it, built in days — tells you exactly what the system must do. If you build, it is the specification. If you buy, it is the scorecard every vendor is judged against, feature by validated feature, rather than by the demo. Either way you are months ahead of a conventional RFP, and you will not buy a product that cannot do the nine things your users said they cannot live without.

The honest caveat

AI makes building cheap enough that an operations team can now build a system themselves. Some should. The failure mode is not that it cannot be done; it is that the resulting system quietly becomes the next key-person risk — undocumented, untested, understood by one person. The fix is an experienced engineer in the room at the right moments: architecture up front, review as you go, and hand-over discipline at the end. That is a fraction of a traditional build's cost and most of its value.

Frequently asked

Is it cheaper to build or buy software now?

For workflows that are specific to your business, building with AI-accelerated engineering is now often cheaper over three years than licensing a product that fits badly. For commodity functions, buying still wins.

How long does a bespoke AI-accelerated build take?

Typically eight to sixteen weeks for a production system, after a workshop and a clickable prototype in the first three weeks.

What is the risk of building ourselves with AI tools?

Key-person risk and lack of engineering discipline: undocumented, untested systems understood by one person. A guided build with a senior engineer reviewing architecture and code avoids this.

Should we do an RFP first?

Do a Living Requirements Document first. It tells you what you need before you ask vendors, and becomes the scorecard if you buy or the spec if you build.

The sooner we talk, the further ahead you finish.

Thirty minutes with a senior engineer. You leave with a scoped first build and a clear read on build vs buy, whether or not you hire us.

Book a build call