We build custom software, so our advice on whether to build custom software deserves scepticism. This is the framework we actually apply, including the cases where the answer is to buy.
Start with what makes you competitive
The first question is whether the process in question is a source of advantage or simply something the business has to do.
Payroll is not a differentiator. Neither is email, accounting or helpdesk ticketing. Buy those. Forcing a distinctive process into a generic product is the mistake, and so is building a generic process from scratch.
Where your pricing logic, fulfilment model or underwriting approach is genuinely different from competitors, that difference is worth building around — a package will force you toward the average.
Count the real cost of both options
Build cost is not just development. It includes maintenance, hosting, security patching, the cost of the people who understand it, and the opportunity cost of engineering attention.
Buy cost is not just the subscription. It includes implementation, customisation, integration, per-seat growth as you hire, the price increase at renewal, and the cost of eventually migrating off it.
Comparing a build quote against a monthly subscription without projecting both over five years produces a misleading answer in whichever direction the person doing the comparison prefers.
Ask what happens at the boundaries
Most package failures happen not in the core function but at the edges — where it has to integrate, where a report is needed in a specific format, where a workflow has an extra approval step.
Before buying, test the boundaries specifically. Can you export your data completely? Can it integrate with the systems that matter? What is the escalation path when a limitation blocks you? A product that handles eighty per cent of the requirement elegantly and makes the remaining twenty impossible is often worse than one that handles it all adequately.
The hybrid answer is frequently correct
Build and buy is not binary. A very common outcome is buying the commodity components and building the thin layer that connects them to a distinctive process.
Keep the accounting package. Keep the helpdesk. Build the operations system that is genuinely specific to your business, and integrate.
When we tell clients not to build
When the process is standard and a mature product exists. When the team is too small to maintain what we would deliver. When the requirement is urgent and a package can be live in weeks. And when the budget is sufficient to build but not to maintain — which produces the worst outcome of all: a custom system nobody can safely change.