When to build custom software, and when to just buy it

Almost every business reaches a point where the tools no longer fit. The spreadsheet has grown a tab nobody understands, the subscription platform does eighty per cent of what is needed, and the remaining twenty per cent is handled by someone manually every Tuesday. The question that follows is whether to build something.

It is usually asked as a budget question, and it is not one. Build and buy fail in different ways, and the right decision depends on which failure your business can absorb.

What each option actually costs

A subscription looks cheap because the price is on the website. The real cost includes the workarounds — the export-to-spreadsheet step, the field being used for something it was not designed for, the process bent to fit the tool. Those are rarely counted, and on a long enough timeline they can exceed the licence fee substantially.

Custom software looks expensive because the build cost is quoted up front and paid visibly. What the quote frequently omits is the rest of the life of the thing: hosting, dependency updates, the change needed when a tax rule moves, and the fact that somebody must remain able to modify it. Software is not a capital purchase that sits there. It is closer to hiring — an ongoing obligation you have taken on.

The test that actually separates them

Ask whether the process is a competitive advantage or an industry norm.

Payroll is an industry norm. Every business does it, the rules are external and identical for everyone, and doing it unusually well wins you nothing. Buy it. Anything a competitor could copy from you by buying the same product is, by definition, not differentiating.

But most businesses have one or two processes that genuinely are theirs — a way of quoting, scheduling, or matching supply to demand that is the reason customers choose them. Forcing that into a generic tool erodes precisely the thing that makes the business work. That is where building pays.

• Would a competitor gain on you by using the same off-the-shelf product? If no, buy it.
• Does the workaround exist because the tool is generic, or because your process is genuinely unusual?
• Is the process stable enough to encode, or still changing every quarter?
• If the person maintaining this leaves, what happens?
• Could you buy 80% and build only the differentiated 20%?

That last question is the one most often skipped, and it is usually the right answer. The choice is rarely all-or-nothing: buy the CRM, build the quoting engine that makes your CRM worth having.

Signals you are about to build the wrong thing

• The specification was written before anyone watched the work being done
• The main driver is dissatisfaction with a vendor rather than a specific capability gap
• Nobody can name the metric the system is supposed to move
• The requirements describe a product category, not a problem
• The plan is to replace everything at once rather than one workflow first

We will tell you to buy when buying is right. A build that should have been a subscription is expensive for you and a poor reference for us, and neither of those is worth a quarter of revenue.

If you do build

Ship one workflow into real production use before building the second. A narrow system people actually use beats a complete one in staging, and real usage will contradict at least one thing in the specification — better to discover that in week four than month nine.

This is the thinking behind Build Digital Systems.