Build or buy: working out which is actually cheaper

Most build-versus-buy conversations start with a subscription price and a development quote, and that comparison is close to meaningless. One is a recurring cost that rises with headcount; the other is a one-off cost with a maintenance tail. They are not the same shape.

A more useful question: is this process one of the reasons customers choose you?

Buy, without hesitation, when the process is standard

Accounting, payroll, email, calendars, document storage, video calls. Nobody chooses a supplier because their payroll is unusually good. These are solved problems with mature products, and building your own is a way of spending money to end up slightly behind.

The same is true of anything with a regulatory surface you would rather not own — tax filing, statutory reporting. Let a vendor carry the burden of keeping up with the rules.

The 70% test

A common rule of thumb: if the best available product covers around 70% of what you need, buying is usually still right, and you change your process to fit the remaining 30%.

The trap is what happens when you refuse to change the process. The gap gets filled with spreadsheets, exports, a shared inbox and someone re-keying between two systems. That workaround has a cost, it is paid every week, and it never appears in the comparison because nobody invoices for it.

Count the workaround. If three people spend an hour a day each holding a bought system together, that is the real subscription price.

Four conditions that shift it towards building

• The workflow is a competitive edge. If how you do it is part of why you win, a product that makes you work like everyone else removes the edge.
• Nothing off the shelf gets past about 70%. Not one product — you have actually looked.
• Compliance requires control you cannot get. Data residency, retention or deletion behaviour a vendor will not commit to.
• Per-seat pricing is scaling faster than the value. Subscription cost that grows with headcount while the benefit per person stays flat.

One of these is rarely enough. Two or three usually is.

How to work out your own break-even

You do not need a consultant for this. Take the annual subscription across the seats you will actually have in three years, add the cost of the workaround time, and compare it with the build cost plus a realistic maintenance figure — expect maintenance to be a meaningful annual fraction of the original build, not zero.

Then extend both to five years. Custom software is a capital cost with a running tail; SaaS is a running cost that compounds. Which one wins depends almost entirely on the seat count and how long you keep it.

If the answer comes out close, buy. A close call means the process is not distinctive enough to be worth owning.

What buying hides

Two costs rarely make it into the comparison. The first is exit: getting your data out in a usable shape, and what it costs to move if the vendor raises prices or is acquired. The second is integration: a bought product that will not talk to the rest of your systems creates exactly the double-entry the purchase was meant to remove.

Ask about both before signing, not after.

Common questions