Custom build or off-the-shelf? A decision test

Buy when your process is conventional. Build when the process is the thing that makes you different, or when you are paying for a product and then paying again in workarounds to make it fit.

That is the whole answer. The rest of this article is how to tell which situation you are in, and it is worth noting that we sell custom builds and still recommend buying more often than not — because delivering the wrong thing is more expensive for us than losing the project.

The five questions

1. Is this process the reason customers choose you?

If your dispatch scheduling is genuinely better than your competitors', software that encodes it is an asset. If your invoicing is the same as everyone else's invoicing, encoding it in custom software buys nothing. Most businesses have one or two processes that are genuinely theirs and a dozen that are ordinary. Build the first, buy the rest.

2. Have you already bought something and built workarounds around it?

Count the spreadsheets that exist to compensate for the tool. Count the steps your team performs because "the system won't let us". If that list is long and growing, you are already paying for custom software — in salary rather than licence fees, and without owning anything at the end.

3. Could you describe the rules to a new employee in an afternoon?

If yes, a configurable product will probably hold them. If the honest answer is "it depends, and there are exceptions Ramesh knows about", that complexity has to live somewhere. Products handle exceptions badly; that is what makes them cheap.

4. What happens when the vendor changes direction?

Products get acquired, repriced, sunset, or pivoted toward a different market. If the tool sits at the centre of your operation, that is a real risk with no mitigation other than migrating. Weigh it honestly rather than assuming today's roadmap is permanent.

5. Is the requirement regulatory, or does it involve multi-entity separation?

Multi-campus, multi-branch, multi-legal-entity setups are where products most often break. They usually offer a "location" field rather than genuine scoping, which means data separation is a filter someone can forget rather than a boundary the system enforces. If you need to prove one branch cannot see another's records, check very carefully how the product actually implements it.

The two ways this goes wrong

Building what you could have bought. The expensive version. You spend months and a budget building a worse version of something that already exists, and then you own its maintenance forever. The warning sign is a requirements document that reads exactly like a product's feature list.

Buying what you needed to build. The slow version, and more common. The tool is 80% right, the missing 20% is the part that matters, and the gap gets filled by people doing manual work. The cost is invisible because it never appears on an invoice — it appears as headcount and as errors.

The middle option people forget

You do not have to choose for the whole business. The pattern that works well: buy the commodity systems, build the one that is genuinely yours, and integrate them properly. Your accounting stays in an accounting product. Your dispatch scheduling — the thing you are actually good at — gets built. The integration between them is a fraction of the cost of building either from scratch.

This is the answer for most established businesses, and it is the one that gets recommended least, because it does not fit neatly into either vendor's pitch.

If you are still unsure

Write down the three things the system absolutely must do that you believe no product does. Then spend an afternoon checking whether that is true. Half the time it is, and you have a clear case for building. The other half, you have saved yourself a project.