Buy when your process is ordinary. Build when the process is the thing you are actually good at. Integrate when it is both, which is most of the time and the answer people arrive at last.
That is the whole procedure. The rest of this is how to tell which case you are in, because almost everybody guesses wrong in the same direction.
Buy, when the process is ordinary
Payroll. Accounting. Email. Calendars. Storing documents. Signing things.
None of these are where a business wins, and all of them are solved to a standard no custom build will reach for the money. If your process here differs from the industry default, the honest first question is whether the difference is an advantage or an accident. Usually it is an accident — a habit that formed around a limitation somebody worked around in 2016, and which everyone now treats as how things are done.
Changing your process to match good software is a real option and it is under-considered, because it feels like losing. It is often the cheapest correct answer.
Build, when the process is the advantage
The test is whether a competitor could buy their way to the same capability.
If the way you route jobs to the floor, or price a quote, or decide which order ships first, is genuinely part of why customers choose you, then software that encodes it is worth building — and software that forces you into someone else's model of that process is actively expensive, because it makes you slightly more like everybody else.
This is a narrower category than most people think, and much narrower than most people are told. Building is also a commitment: something has to be maintained, someone has to own it, and it will need attention when the business changes. That is fine when the thing being maintained is the source of an advantage. It is a poor trade for an expenses form.
Integrate, when it is both
This is the case nobody plans for, and the one almost everyone ends up in.
The parts of your business that are ordinary run on tools you bought. The part that is distinctive needs something of its own. And the value shows up where they meet: the quote your salesperson builds in the CRM has to become a job on the floor, then a packing list, then an invoice, without three people retyping it.
Most of the useful work we do is that seam. Not a system replacing what you have, but the connective tissue that stops your team acting as a manual API between two things that both work fine on their own. It is unglamorous, it is rarely what somebody asks for on the first call, and it usually produces a bigger change than the thing they did ask for.
The trap to know about: integration cost lives in the other system's quirks, not in yours. A vendor's export that omits one field, an API that rate-limits at an awkward number, a system with no way to know something changed except asking it repeatedly. None of that is visible from outside, which is why an integration estimate given before someone has looked at the far end is the least reliable number in this business.
Two failure modes, and which one you are prone to
Building what you could have bought is the expensive mistake, and it comes from pride in a process that is not actually distinctive. The symptom is a requirements document that describes a well-known category of product with three small differences, each of which someone insists is essential.
Buying what you should have built is the slow one. Nothing dramatic happens. You just spend a few years bending the thing you do well into the shape a vendor expects, and the advantage quietly erodes. The symptom is a spreadsheet that exists alongside the official system because the official system cannot express what the team actually needs.
If your team maintains a shadow spreadsheet, that spreadsheet is a specification. It is a description of the gap between the software you bought and the work you do, written by the people who do the work, for free. Read it before you decide anything.
Where we land, usually
Some combination. A bought system for the ordinary parts, something built for the part that matters, and a considered seam between them. That is less satisfying than a single decisive answer, and it is what tends to survive contact with a real business.
The assessment exists to work out which pieces fall where before anything is committed to — that is what advisory is for, and it is the stage most worth doing even if you never build anything with us. If the answer is that you should buy something and change one process, we will say so.