Build or buy software? The test we apply

The five questions

Run each process through these separately — sales pipeline, payroll, dispatch, quoting, onboarding. Answering them at company level is how organisations end up rebuilding accounting software.

1. Is this process how you compete?

Your dispatch logic, your pricing rules, your underwriting steps, the way you sequence a job — these are the reason customers choose you. Handing them to a generic product flattens the thing you are good at. Everything else is table stakes, and table stakes should be bought.

2. Does a product cover it without a workaround your team performs daily?

The word doing the work here is daily. Every product has gaps; the question is whether the gap is a monthly annoyance or a step someone repeats fifty times a shift. A daily workaround is a cost you are already paying, just not on an invoice.

3. How often does the process change?

Custom software freezes a process. Freeze the wrong one and you have paid to make it permanent. If nobody in the business can describe the current version without arguing, that disagreement is the project — not the software.

4. What does the licence cost at your headcount in three years?

Per-user pricing is cheap at twelve people and a serious line item at ninety. The maths turns at a smaller team size than most founders expect. Run it forward before deciding, because the comparison is not licence-today against build-today.

5. Who owns it after launch?

Software without a named internal owner rots faster than the licence you were avoiding. If nobody will own it, buying is the honest answer — a vendor's roadmap is at least someone's job.

Three routes, compared

There are not two options. Configuring an existing platform sits between buying and building, and for a great many processes it is the right answer.

Scroll the table sideways for all three routes.

Where we tell clients to buy

These are solved, inexpensive relative to building, and regulated in ways you do not want to own. If you ask us to build one, we will ask what is wrong with the product first, and the honest answer is usually "nothing, we had not looked".

• Accounting and bookkeeping — Xero, QuickBooks, Zoho Books. Tax rules change annually and someone else should be tracking them.
• Payroll and HR records — Zoho People and equivalents. Statutory reporting is a moving target with penalties attached.
• Helpdesk ticketing — Freshdesk, Zendesk. A mature product costs less than the reporting layer alone.
• E-signature — DocuSign. The value is legal admissibility, not the interface.
• Issue tracking — Jira, Linear. Building your own is a rite of passage worth skipping.
• Standard online retail — Shopify. Hosting, PCI scope and checkout become someone else's problem, which is worth the platform fee for most catalogues.

The customisation trap

Configuring a platform is often right. Past roughly thirty per cent customisation it becomes the worst of both worlds: you are maintaining bespoke logic and paying licences and carrying upgrade risk every time the vendor ships a release.

The warning sign is countable rather than philosophical — the number of custom scripts, workflows and field overrides that nobody has documented. When that list gets long enough that an upgrade requires a testing project, you have arrived. At that point the honest options are to simplify back toward the standard product, or to accept that this process wants a custom system and move it out. We flag that line when we see a client approaching it, including when the client is paying us to do the customising.

The usual answer is mixed

A typical mid-sized company ends with a licensed core for the ordinary processes, a custom layer where it genuinely differs, and an integration between them. That integration is not an afterthought — it is where most of the operational risk lives, and it deserves the same scrutiny as the build itself. We set out how those connections are built and monitored in why integrations fail silently.

If you are weighing a custom build, custom software development covers how we scope and deliver one. If the question is really about CRM, ERP or HRM, enterprise applications covers the configure-versus-build decision in more depth. And engagement models explains why we recommend a paid discovery before quoting either — the specification it produces is yours whether or not you build with us.

More guides from the delivery team are collected on the insights index.

Published: 23 August 2026 Last updated: 23 August 2026 Written by the Canopus delivery team