Comparisons · · 4 min read

Build vs buy software: how the decision works for AI and data

Cost both options on the same lines. When a vendor product wins, when building with your own engineers wins, and the hybrid that costs more than either.


Buy when a vendor product already covers most of the requirement and your own data is not what makes the output good. Build when the value sits in data only you hold, in an integration surface no vendor prices for, or in a workflow that changes faster than a product roadmap. Most build-versus-buy arguments go wrong before the numbers appear, because the two options get costed on different lines: the licence is compared against engineer day rates, and the data work that both options need never enters the buy column.

Cost both columns the same way

Take a 24-month horizon and put identical lines in each column.

Cost lineBuyBuild
Licence or subscription€40k to €200k a year for mid-market AI and data toolingnone
Integration and data preparation30 to 80 engineer days30 to 80 engineer days
Core buildnonetwo to three engineers, four to eight months
Change and runvendor roadmap, plus 10 to 20 days a year of your own team15% to 25% of the original build effort a year
Exitre-platform, two to four monthsthe code stays in your repository

The second line settles more cases than the first. Getting your data into a shape a model can use costs roughly the same either way, because no product reads twelve years of free-text CRM fields on your behalf. If your evaluation shows integration at five days for the bought option and sixty for the built one, the evaluation is wrong, not the options.

When buying wins

When building wins

The hybrid that costs more than either option

The expensive outcome is buying a platform and then building a second system around it to compensate for the parts that do not fit. It carries both cost structures and neither set of benefits. Watch for one signal: the share of engineer time spent on workarounds rather than features. Past about 40%, you have paid for a product and built one anyway, and the cheaper correction is usually to keep the product for the narrow thing it does well and move the rest into your own code.

For the build column, day rates and blended team costs move the answer more than any other input, so use current figures from our published daily rates and size the effort with the project cost calculator before the debate becomes philosophical. The drivers behind those numbers are set out in our note on what actually moves the cost of an AI build.

Where renting engineers is the wrong answer

Four cases where you should not call us:

  1. The requirement is genuinely commodity. Buy the product, integrate it in six weeks, spend your engineers on something a vendor cannot sell you.
  2. Nobody internal owns the roadmap. Rented engineers build what you specify. With no specifier, you get an expensive prototype and a maintenance liability.
  3. The work is under about twenty days. Onboarding overhead eats the benefit.
  4. You want a single throat to choke on a fixed outcome. That is a delivery contract, not time-and-materials capacity.

If none of those apply, the decision is arithmetic, and the arithmetic is usually decided by the integration line rather than the licence.