Buy or build: how to actually decide

The question is usually asked too early

Buy or build normally comes up before anyone has written down how the work is currently done. At that point the comparison is between a product demo, which looks complete, and a hypothetical build, which looks expensive and slow. Buying wins that comparison almost every time.

It is the wrong comparison. The real one is between the product as it will behave once your process meets it, and a build scoped only to the parts the product cannot do. Both sides of that comparison need the process written down first.

What buying is genuinely good at

Anything where your process is the same as everyone else's, and where being different would be a liability rather than an advantage. Accounting. Payroll. GST filing. Email. Any regulated format where a vendor tracking the rule changes is worth far more than control.

The test is not how important the function is. Accounting is critical and you should still buy it. The test is whether doing it your own way creates any advantage at all. For most compliance and back-office functions, it does not.

Where products break in logistics

Logistics operations differ from each other in ways that are invisible in a demo and decisive in daily use. A warehouse's usable layout, the sequence in which a customer requires documents, how detention is calculated with one particular client, which approvals a branch manager can give and which they cannot.

Products handle this with configuration, and configuration has a ceiling. Below it, the product bends. Above it, your team starts working around the software — a spreadsheet beside the terminal, a WhatsApp group carrying the real status. That workaround is the honest verdict on the fit, and it usually appears within a month of go-live.

So the question is not whether a product covers your requirements. It is whether the places it does not cover are places you can afford to change how you work.

The cost of building is not the build

Teams routinely estimate the build and forget everything after it. Someone has to run the servers, apply security patches, hold backups that have actually been restored, respond when it breaks at 11pm, and keep changing it as the business changes. That is the real bill, and it does not stop.

This is the strongest argument for buying, and it is rarely the one people make. They argue about development cost, which is the smaller and more predictable half.

If you build, budget for the keeping. If you cannot, buy — or find someone who will carry that part for you.

A test that usually settles it

For each system, ask: if a competitor copied exactly how we do this, would we lose anything?

• No, and it is regulated — buy, without discussion
• No, and it is generic — buy, and stop customising it
• Yes, but only in a few specific steps — buy the base, build those steps, integrate
• Yes, and it is how we actually compete — build it, and own it properly

The hybrid answer is usually right

The most common good outcome is not a clean buy or a clean build. It is buying the commodity layers, building the two or three things that are genuinely yours, and connecting them so data moves once rather than being retyped.

That path also fails in a predictable way: nobody owns the integration. Bought systems come with a vendor, built systems come with a team, and the wiring between them comes with neither unless someone is made responsible for it.

Why we built

Vistar Logitek's operations did not fit the products available at a price that made sense, and the workarounds were already accumulating. Building was the better trade for that specific situation.

That is not a general recommendation, and we will say so on a call. If a product fits your operation, buy it — you will spend less and sleep better. The work worth doing together is the work no product covers.