Custom software vs off the shelf, decided in the right order

The question arrives as a budget question. Somebody has a quote for a custom build and a subscription price for a product that does most of it, and they would like to know which is cheaper. It is a reasonable question and it is not the one that decides the outcome, because both numbers are estimates and the custom one is an estimate of work that has not been specified yet.

The decision that holds up is made on three other questions, and they can be answered before anyone quotes anything. This note is about those questions, and about the default you should fall back to when the answers are unclear.

Start with how common your need actually is

The UK Government Digital Service has been making this decision at scale for over a decade, and its guidance is unusually blunt about the first test. In its note on whether to build or to buy, the framing is that if your requirement is common and well served by suppliers you should buy, and the worked example is email: nobody sensible builds an email service.

The useful version of this test is uncomfortable, because most businesses believe their needs are unusual and most are wrong. The honest way to run it is to describe your process to someone in a different company in the same industry and see whether they recognise it. If they do, a product exists for it. If they wince and say they do it differently, you have found something real.

Being genuinely unusual is not automatically a reason to build, either. Sometimes the discovery is that your process is unusual because it grew by accident, and the correct fix is to change the process rather than to encode it in software that will now be expensive to change.

Then ask whether it is core to what you do

The same guidance draws the line at core function: a passport-checking tool belongs in-house at an organisation whose job is passports, and its email does not. Translate that to a commercial business and the test is whether this system is part of what customers pay you for, or part of the overhead that lets you deliver it.

A row that gets skipped is the last one. GDS puts it plainly: you cannot outsource risk. Whichever route you take, somebody at your organisation has to understand the system well enough to own it, and if that person does not exist then buying is the safer choice regardless of what the other rows say.

The customisation trap

The worst outcome in this decision is not building when you should have bought, or buying when you should have built. It is buying a product and then paying to make it behave like a custom one.

The guidance is explicit that configuring an off-the-shelf product is fine and customising it is where the costs go. Configuration is using the settings the vendor built for the purpose. Customisation is paying someone to make the product do something it was not designed for, and it produces a system with the constraints of a product and the maintenance burden of a build, upgraded at the vendor's pace rather than yours.

If your evaluation of a product includes a line for bespoke development against it, that is the moment to re-run the comparison honestly, because you are no longer comparing buy against build. You are comparing two builds, one of which starts on top of somebody else's foundations and cannot be changed freely.

What the cost comparison actually hides

• A subscription is a running cost that scales with headcount. A build is a large one-off plus a smaller running cost. Comparing them over one year flatters the subscription and comparing them over ten flatters the build, so pick the horizon deliberately rather than by accident.
• The build number is an estimate of unspecified work. It will move. The subscription number is a price someone is contractually offering you, and it will also move, just less visibly and at their discretion.
• Neither number includes the cost of the workarounds you are running today, which is real money and is currently invisible because nobody invoices for it.
• Neither number includes migration, which is where buy-versus-build projects most often overrun regardless of direction.

We have written the arithmetic out for one concrete case in how much a custom CRM costs, and the ongoing side in software maintenance cost after launch. The second is the number people forget, and it is the one that decides whether a build was a good idea three years later.

The hybrid answer is usually the right one

Framing this as a binary is what makes it hard. Most businesses that end up happy buy the commodity parts, build the one thing that is genuinely theirs, and connect them.

Accounting, email, payroll and storage are bought. The scheduling logic that is the reason customers choose you, or the pricing rule nobody else applies, is built. The integration between them is the actual project, and it is smaller and less risky than either extreme.

There is also a middle tier worth testing before committing to either: no code versus custom development covers where no-code genuinely holds and the specific points at which it stops.

The default when you cannot decide

If the answers are genuinely ambiguous, buy. Buying is the reversible decision. A subscription you regret costs you a notice period and a migration. A build you regret costs you the build, the migration, and the year you spent on it.

The exception is when the thing you would be buying does not exist. Not "exists but is imperfect", which describes every product ever sold. Genuinely does not exist, which you can only claim honestly after looking properly. Signs you need custom software lists the states where that claim tends to be true.

The honest limits

This decision is easier to get right at the extremes than in the middle, and most real cases are in the middle. Anyone who gives you a confident answer without asking about your team, your rate of change and who will own the thing in year three is selling one of the two options.

Our own bias is worth naming: we build custom software, so treat the argument for building as coming from an interested party. The check on that is the default above. We tell people to buy fairly often, and the cases where we do are the ones in the first two rows of the table: a common need, well served, in a part of the business nobody chooses you for.

Finally, do not make this decision without a scope. The comparison is meaningless while one side is a wish. How to scope a software project is the step that makes both numbers mean something.