Build, buy, or integrate: the question most organisations ask too late
The decision is usually framed as build against buy. That framing is what causes the expensive mistake, because it hides the third option that fits most situations.
Written for chief information officers, chief operating officers and founders.
A false choice
Build against buy is a comfortable question because both answers are procurable. One is a project, the other is a licence, and either can be put in front of a board.
The trouble is that most organisations are not choosing on a blank page. They already run several systems, each doing part of the job adequately. The real question is not what to acquire. It is which of the things you already have should stay, and what has to exist between them.
When buying is right
Buy where the process is genuinely standard and you have no intention of differentiating on it. Accounting, payroll and email are solved problems, and an organisation that customises them is usually paying to make its own life harder.
The test is honest and uncomfortable: if the product requires you to change how you work, is that change an improvement or a concession? Standard software imposes a standard process. Where the process is not the thing that makes you good at what you do, that is a gift rather than a cost.
When building is right
Build where the process is how you compete, where no product models it properly, or where the exceptions are the business. Every organisation has a handful of these, and they are usually the parts that get run on spreadsheets precisely because no vendor would model them.
Building is also right when the alternative is configuring a product so far past its intent that you have built something anyway, without owning it, and with an upgrade path that will eventually take it away from you.
Why integrate is usually the answer
The third option gets skipped because it is the least satisfying to present. It does not produce a new system to point at. It produces the appearance of one.
A translation and synchronisation layer lets each existing system keep its own model while the organisation reads and writes one authoritative record. The finance system stays the finance system. The operational system stays operational. What changes is that they stop disagreeing, and the work that used to cross between them by email starts crossing automatically.
It is cheaper than replacement, faster to deliver, and reversible in a way a migration is not. It also tends to reveal, within a few weeks, which system genuinely needs replacing and which one was only ever annoying.
How to decide
Map how the work is actually done, exceptions included, before choosing anything. Then ask three questions of each system in the estate: is it doing its job, is it in the way, and would replacing it change the outcome for the business or only for the people who dislike it?
Most estates come out of that exercise with one or two systems to replace, several to connect, and a short list of processes that genuinely deserve to be built. That is a far better paper to take to a board than a choice between two vendors.