Build or buy: when custom software is the cheaper option

"Just buy something off the shelf" is good advice, and it is right most of the time. A tool that thousands of companies use has had its edge cases found by people who were not you, and it costs less on day one than any custom build ever will.

The trouble is that the comparison people run is between a subscription and a build, when the honest comparison is between the whole cost of living with a tool and the whole cost of owning one. Those two lines cross more often than the SaaS-first orthodoxy suggests, and the crossing point is not where most people expect.

The costs nobody puts in the spreadsheet

The subscription is the visible number, and it is usually the smallest one. Underneath it sit four costs that rarely make it into the comparison.

Seat inflation. Per-user pricing is a tax on growth. It also quietly shapes behaviour: teams start sharing logins, or leaving people off the system, and the data quality degrades in ways that are invisible until you need a report.

The integration tax. Tool A does not talk to tool B, so you buy a third tool to connect them, or you pay someone to maintain the connection, or — most commonly — a person becomes the integration. Someone exports a CSV every Monday. That person is a line item.

The workaround tax. This is the big one and the hardest to see. Every place your process does not match the software's assumptions, your team invents a workaround: a spreadsheet on the side, a naming convention in a free-text field, a rule that lives only in someone's head. Workarounds are unpaid, unlogged, and they compound. When someone leaves, the rule leaves with them.

The exit cost. What does it take to get your data out in a usable shape? For some tools the answer is an afternoon. For others it is a project, and knowing which you have bought is worth finding out before you need to know.

Add those up over three years and compare that to a build. The comparison looks different.

The four signals

In practice, four things reliably indicate that the crossing point has been passed.

1. Your process is the product. If how you do the thing is a reason customers choose you, software that forces you into somebody else's version of that process is not saving money. It is eroding the thing you compete on.

2. You are paying for ninety per cent you do not use. Enterprise platforms are priced for the whole feature surface. If you use a tenth of it and the tenth you use is not quite right, you are subsidising other people's requirements.

3. The spreadsheets have become load-bearing. Not "someone keeps a spreadsheet" — everyone keeps a spreadsheet. Load-bearing means: if that file were deleted on a Friday, would Monday work? When the answer is no, the real system is the spreadsheet and the software is decoration.

4. You want to sell it. If the thing you have built internally would be useful to people in your industry, that is a different conversation entirely — and it is one where owning the software is the entire point.

None of these is decisive alone. Two together usually is.

What custom actually means now

Part of what makes the old advice out of date is that "custom" no longer means writing everything.

A serious custom build in 2026 is mostly assembly: managed authentication, a managed database, a payments provider, a hosting platform that handles scaling. The bespoke part is your domain — the rules, the workflow, the screens your team spends its day in. That is the part no vendor can sell you, and it is a much smaller slice of the work than it was a decade ago.

This changes the arithmetic. It also changes the risk: a build that leans on managed services has far fewer places to go badly wrong than one that owns its own infrastructure.

The hybrid answer, which is usually right

The real answer is rarely all of one or the other. The pattern that works:

• Buy the commodity. Accounting, email, payroll, payments, video calls. There is no advantage to be had here and a great deal of pain to be bought.
• Build the differentiator. The workflow that is actually yours. The thing you would describe to a competitor with some reluctance.
• Integrate deliberately. One system holds the truth for each kind of record, and everything else reads from it. The costly mess is not having several tools; it is having several tools that each believe they are the master copy.

Before you decide

Write down the process as it actually runs today, including every workaround, every spreadsheet and every "and then Sarah checks it." Two things tend to happen when people do this.

Sometimes the process turns out to be a mess that no software will fix, and the right move is to simplify it first and buy something ordinary afterwards. Sometimes the process turns out to be genuinely, defensibly yours — and the tool has been quietly taxing it for years.

Either answer is worth the afternoon it takes to find out, and it is a much better basis for a decision than a feature comparison chart.