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 — it is three years of licences against building once and maintaining it. If you need the build half of that sum, what drives the cost of a SaaS MVP sets out the four decisions that move the number more than the feature list does.

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.

AI features are the category where this test is applied worst. The question is usually posed as build-or-buy when the real fork is earlier: whether you need the model to know something or to behave a certain way. Get that wrong and you buy a fine-tuning project to solve a retrieval problem, which is expensive and slow to discover because the output still reads plausibly. Retrieval or fine-tuning — which your AI actually needs sets out how to tell them apart before any of it is priced.

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.

When the test does come back build, the questions left are commercial rather than technical: fixed price versus time and materials sets out which contract shape holds up while the scope is still moving, and which one quietly charges you for changing your mind. More guides from the delivery team are collected on the insights index.

Questions

Awkward cases: disagreement, migration and exit

Two departments describe the same process differently. Whose version goes through the test?

Neither, usually — disagreement is the signal that you are looking at two processes wearing one name. What sales calls quoting and what finance calls quoting often share only the number at the end. Map each version separately, run the five questions on each, and the answers frequently diverge: buy one, build the other. If the versions really are identical and the argument is about who owns the process, that is an operating decision and no software settles it. Building at that point just makes one department's version permanent.

What does thirty per cent customisation actually look like, and how do we count it?

Count artefacts, not feelings. Open the platform's admin and list every custom field, custom object, workflow rule, script, plugin, non-standard report and hand-written integration; then list the standard objects you use as delivered. In Salesforce that shows up as Apex classes and triggers, in Dynamics as plugins, in Odoo as custom modules, in Zoho as Deluge functions. Thirty per cent is roughly the point at which accepting a vendor release requires its own regression test. If nobody can produce that list in an afternoon, the real number is higher than the one you would have guessed.

We already run a product. Is it worth migrating off it?

Rarely for the reason people give. The licence is what gets quoted and the migration is what gets forgotten: data extraction and cleaning, records you are legally required to retain, retraining, every integration pointing at the old system, and a stretch of running both in parallel. Price that whole move before comparing anything. The cases that survive the arithmetic are a workaround your team performs daily, or per-seat pricing against headcount you actually intend to double — not irritation with the vendor's interface.

How do we compare three years of licences against a build without flattering one side?

Both columns get understated, in opposite directions. The buy column usually leaves out the seats you will add, the admin hours spent keeping the configuration alive, and the daily workaround from question two — that one sits in payroll rather than on an invoice, so it never reaches the spreadsheet. The build column usually leaves out hosting, dependency patching, the support retainer once the 30-day defect window closes, and the internal owner's time. Put all of those into the same three-year table and the totals land closer together than whoever is arguing for either side expects. We will price the build column properly before you decide, including the lines that make it look expensive — a comparison that only holds up because half the costs are missing is not a decision, it is a purchase somebody already made.

If we build custom and later want to move off it, what happens to our data?

You keep it, because you own the database. It runs in your own cloud account and full IP assignment on final payment covers the source, the schema and the migrations, so a standard Postgres dump is the export — no ticket to raise, no vendor to ask for permission. What sets the real exit cost is whether the data model makes sense to someone who did not build it: tables named after the business rather than the sprint, status values enumerated and written down, foreign keys enforced in Postgres rather than only in application code. Put those in the acceptance criteria at kick-off, where they cost nothing, instead of asking for them at handover as a change request. A system you cannot leave is a licence with extra steps.

We have nothing written down. Is that a blocker before you can quote?

It is not a blocker, but it changes the first step: undocumented work has to be observed before it can be priced. Sit with the three or four people who actually perform it and record what each one does, including the spreadsheet steps nobody mentions in meetings. The variance that surfaces is usually deliberate — different customers, regions or exceptions — rather than sloppiness, and deciding which variants survive is the expensive decision, not the code. A paid discovery is where that gets settled, and it ends with a written process map and a costed plan you can put in front of a product vendor just as easily as in front of us.

Who maintains a custom build if the internal owner leaves?

Design for that on day one rather than on the day the resignation arrives. The owner's job is deciding what changes, not remembering how it works, so the handover has to carry the knowledge instead: infrastructure-as-code that runs, a README that gets a new engineer to a working local environment, and the CI pipeline that deploys it. Past the 30-day post-launch defect window most clients keep a support retainer for monitoring, dependency patching and small changes, with 30 days' notice either direction. If you want neither an owner nor a retainer, that is a real argument for buying, and we will say so.

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