When custom software is worth it, and when it isn't
A software company recommending custom software is not a neutral source, so it is worth stating the general case plainly: for most business functions, off-the-shelf software is the right answer. Accounting, payroll, email, helpdesk — these are solved problems where a product serving thousands of companies will be better than anything a single company builds for itself.
The question is which parts of a business are not like that.
The test: does the process differentiate you?
If the way you do something is a reason customers choose you, generic software will eventually force you to do it the ordinary way. That is the strongest argument for building. If the process is one every company in your sector runs identically, building it is spending capital to arrive where a subscription would have taken you.
The awkward middle case is a process that is genuinely distinctive but only slightly. That is where the spreadsheet appears: the product covers eighty per cent, and the remaining twenty is handled manually beside it. Worth watching, because that spreadsheet is a measurement of the gap, and it tends to grow.
The cost picture is not the licence fee
- Buying: subscription per seat, growing with headcount; configuration and integration work; the cost of adapting your process to the product; and the risk that a roadmap you do not control never ships the thing you need.
- Building: a larger cost up front; ongoing maintenance that does not go away; the need to keep some engineering capability available; and full control over what gets built next.
- Both: data migration, training, and the period where the old and new systems run in parallel. This is routinely underestimated in both directions.
Per-seat pricing deserves particular attention, because it scales with your growth rather than with the value the tool delivers. A tool that is good value at twenty users can be poor value at two hundred without having changed at all.
Questions that actually decide it
- Would we still want this exact behaviour in five years, or is it a workaround for something temporary?
- How many people have to change how they work to fit the product, and how much does that cost in practice?
- If the vendor doubled its price or was acquired, what would we do?
- Do we have, or can we retain, someone who understands the system well enough to change it?
That last question kills more custom software than any technical factor. A system nobody understands is worse than a product nobody controls, because at least the product has a support contract.
The strongest case for building
The clearest case is a company whose operating model is genuinely unusual, running at enough scale that per-seat costs are material, with a process that is central rather than peripheral, and with the appetite to own the result. Multi-vendor platforms, operations with unusual fulfilment models, and businesses whose internal workflow is the product often meet all four.
When it is right, insist on the things that make it an asset rather than a dependency: the source code, documented architecture, and deployment pipelines you can run without the people who built it. Custom software you cannot maintain independently has reproduced vendor lock-in with a smaller vendor.