Build or buy: when off-the-shelf software is the right answer

Buy when the process is not yours

Payroll, accounting, email, calendars, CRM, helpdesks, e-commerce. Thousands of businesses do these almost identically, mature products exist, and the vendor spreads development across all of them. You will not out-build that, and you should not try.

Buying also buys you things nobody quotes for: someone else handling security patches, compliance changes, browser updates and the awkward edge cases discovered by ten thousand other users before you hit them.

If your requirement can be met by configuring an existing product, configure the existing product. A supplier who talks you out of that is selling, not advising.

Build when the rules are your own

The case for building is narrow and specific:

• The process encodes rules that are particular to you — your policy terms, your pricing logic, your eligibility criteria
• The work sits between systems that no product connects
• The volume is high enough that a per-seat licence costs more than a system would
• Off-the-shelf exists but forces you to change a process that is genuinely your advantage

That last one is the one people get wrong in both directions. Most processes are not a competitive advantage and changing them to fit good software is the right answer. Occasionally the process is the business, and bending it to fit a product quietly destroys the thing that made you money.

The hybrid is usually the answer

In practice the honest recommendation is often neither: keep the software you have and build the narrow piece that is missing.

Your accounting package is fine. Your CRM is fine. What is not fine is the person retyping between them, or applying a rulebook by hand to something both systems can already see. Buy the systems, build the join — which is a much smaller, cheaper and less risky project than replacing anything.

It is also why we will not push you to replace working software. Migrations are expensive, disruptive, and usually solve a problem you did not have.

The cost everyone forgets

People compare a build price against a licence fee. That is the wrong comparison, because it prices construction and ignores ownership.

Custom software needs maintaining. Rules change, dependencies age, APIs get deprecated, and a system nobody updates decays until one day it silently stops. Any build quote that does not include ongoing support is not cheaper than the alternative, it is just incomplete.

Ask what maintenance covers and what it costs before comparing anything. Our own pricing is set out in full on the offer page, including the monthly minimum that exists precisely because hosting and monitoring are not free.

How to test a vendor's claim

For off-the-shelf: ask them to demonstrate your actual awkward case, not their demo data. Every product handles the happy path.

For custom: ask what the process costs you today and how they arrived at the figure. A supplier who has measured it answers with volume, minutes and a loaded hourly rate. One who has not answers with a percentage improvement or a case study about somebody else. That single question is covered in more detail in what automation should cost.