Buy vs build software: how to decide without bias

The trap: deciding by preference

Most buy vs build decisions are badly made. Not for lack of analysis, but because of too much bias. An IT department proud of its teams pushes to build; a business unit in a hurry pushes to buy; a supplier recommends whatever it knows how to deliver. Nobody decides on the numbers.

So the right question is never “buy or build?” It is: which option, over five to seven years, costs the least and leaves the most room for manoeuvre?

Three options, never two

“Buy or build” is a false dilemma. There are almost always three options on the table:

• Buy packaged software. Quick to deploy, entry cost under control, heavy dependency over time.
• Build the software the business needs. Higher entry cost, full ownership, an exact fit with the need.
• Modernise what you have. Often forgotten, and almost always the least risky when a core application is still running.

A decision that does not put a figure on the third option is incomplete.

What packaged software really costs

The licence fee is only part of the cost. Over five years, you also have to add:

• annual price increases, often indexed well above inflation;
• add-on modules, which become necessary as usage grows;
• contractual lock-in: a roadmap decided elsewhere, unfavourable exit terms, limited access to your own data;
• specific integrations, almost always underestimated at the outset;
• the loss of in-house know-how in the business process the software now handles.

A vendor that holds your data and your roadmap is no longer a supplier. It is a partner you can no longer leave.

What building really costs

Building costs more up front: that is simply how it works. But the total cost compares well once you factor in:

• full ownership of the code, the data and the hosting;
• no recurring licence fees;
• an exact fit with the business, with no features paid for and never used;
• the ability to evolve the tool at the pace of the business, without waiting for a vendor’s next release.

The real risk of building lies elsewhere: schedule and budget overruns. That is precisely what a commitment to results removes. What will be measured, against what threshold and by what date is written into the contract; if the result is not achieved, the conditional portion is not due.

A four-step method for deciding

Because we can build as well as modernise, we have no interest in pushing one option over another. The decision follows four steps:

1. Scope the need — what the business actually does, not what a product happens to do.
2. Assess the packaged software on the market — on substance, but also on the contract and the exit terms.
3. Calculate the total cost over five to seven years for each of the three options: buy, build, modernise.
4. Recommend, in writing, with arguments that will stand up before an investment committee.

Sometimes the recommendation is “buy”: when a vendor is mature, when the need is the same as everyone else’s, and when the dependency remains manageable. In that case, that is what we write.

When building is the answer

Building becomes the right answer when the need matters to only one client — you — and no vendor has any reason to write the software. Or when buying costs too much in dependency: the roadmap slips out of your hands, and so does your data, and every change becomes a negotiation.

What you get out of it

A decision that is informed and defensible. A transparent total cost for all three options. And a partner with no reason to skew the decision.