Custom software vs off-the-shelf: the only three questions that matter
Buy when the problem is common, the category is mature, and your version of it is ordinary — accounting, payroll, email, e-signature, helpdesk. Build when the process is the thing customers actually pay you for, when no product models your core object, or when the category tools all assume a business shaped differently from yours. Everything else is configuration, which is neither and is usually the cheapest correct answer.
Should we buy software or have it built?
How to decide:
The function is a commodity — accounting, payroll, e-signature, email. Buy. You will never out-build a mature category, and being different here has no commercial value.
The category exists and one product fits most of your process. Configure. Most build projects should have been configuration projects. Exhaust the product first.
The process is your actual differentiator and customers feel it. Build. Handing your differentiator to a product every competitor can also buy removes the reason to choose you.
Every product in the category assumes a business shaped differently from yours. Build. This is the honest signal. If four vendors all model it the same wrong way, no amount of configuration fixes it.
You have a spreadsheet that runs something important and nobody dares change it. Build. That spreadsheet is already custom software. It is just custom software with no tests, no permissions and one owner.
Regulation requires an audit trail the product cannot produce. Build. Retrofitting provable history onto a system that never recorded it is not possible after the fact.
What drives the cost:
Scope, not technology. What a build costs is decided almost entirely by how much of the business you try to model at once. The same team, the same stack and a third of the scope is a third of the cost and a tenth of the risk.
Integration count. Each system the new one must talk to adds cost and permanent maintenance. Two integrations is a project; eight is a programme.
Data migration quality. Migrating clean data is straightforward. Migrating fifteen years of inconsistent records is frequently the single largest line item, and it is discovered late.
Who maintains it afterwards. Custom software has a running cost even when nothing changes. Budgeting the build and not the upkeep is how systems become legacy in two years.
What people get wrong:
Building the whole thing at once. The successful pattern is one painful object first, in production, earning its keep, before anything else is added. Big-bang builds fail on scope, not on code.
Buying to avoid a decision. Purchasing a platform because it is the safe choice, then spending two years configuring it into a shape it resists, is more expensive than either honest option.
Treating a spreadsheet as free. The spreadsheet has a cost: the hours, the errors, and the fact that one person's departure takes the process with them. Compare against that, not against zero.
Is custom software always more expensive?
Upfront, usually yes. Over five years with per-seat licensing and a configuration consultant on retainer, frequently no. The honest answer requires modelling your actual seat count and years rather than comparing a sticker price to a quote.
What is the smallest sensible custom build?
One object and one workflow that currently live in a spreadsheet, in production, used daily. If a firm cannot deliver that quickly, a larger scope with the same firm will not go better.
How do we avoid ending up with legacy software?
Own the code, keep the stack boring and mainstream, insist on documentation, and make sure more than one person can run it. Most legacy horror stories are about ownership and staffing rather than technology.
Should AI change this decision?
It lowers the cost of building, which moves the line — things that were not worth building in 2022 are worth building now. It does not change the logic: commodity functions should still be bought.
Last reviewed 22 August 2026