Custom software vs off-the-shelf: which is right?
Off-the-shelf software is almost always the right answer, right up until it is decisively the wrong one. The difficulty is that the switching point is invisible from inside a company that has been adapting to its tools for years. What follows is how to tell where you actually are.
Buy by default, and be honest about why
Email, accounting, payroll for a standard employment model, CRM, helpdesk, storage — these are solved. A packaged product will be cheaper, better tested and more secure than anything a small team builds, because its cost is spread across thousands of customers and it has been attacked by all of them.
The right question is not “could we build this?” It is “would a customer ever choose us because of this?” If not, buy it, and spend the engineering somewhere it changes the answer.
Five signals that buying has stopped working
- The spreadsheet in the middle. There is a file that two systems both depend on and neither owns. Somebody updates it manually, and everything breaks when they are on leave. That file is a description of the software you need.
- You changed your process to suit the tool. Not adapted — changed. You now do something in a worse order because the software cannot do it in the right one.
- Per-seat pricing punishes growth. The licence cost rises with headcount while the value does not, and you are rationing seats for people who need access.
- Your data cannot answer your questions. The reports the vendor ships are not the questions you ask, and the export is a CSV somebody reshapes by hand each month.
- The workaround has a name. When a manual process is well-known enough to have internal jargon, it has become a system without an owner.
The comparison people get wrong
Build-versus-buy is usually framed as licence fees against development cost, which flatters buying in year one and flatters building thereafter. The comparison that predicts regret is different.
| Buy | Build | |
|---|---|---|
| Upfront | Low | High |
| Ongoing | Licence, rising with seats | Hosting and maintenance, roughly flat |
| Fit | Good for the common case | Exact, and stays exact |
| Hidden cost | Manual work around the gaps | Ownership and upkeep |
| Time to value | Days | Weeks to months |
| Leverage | Same tools as competitors | Whatever you do differently |
The line most often left out is the manual work. Two people spending a combined ten hours a week reconciling systems is roughly a quarter of a salary, every year, invisibly — and it does not appear on any invoice.
The option most people skip
It is rarely all or nothing. The arrangement that works most often is to keep the packaged products for what they do well and build only the connective layer — the piece that owns your particular process and talks to everything else through their APIs.
That is a far smaller build than replacing the tools, it preserves what already works, and it puts the part that is genuinely yours under your control. It is also the honest recommendation more often than a studio saying so has an incentive to admit.
- Buy anything that is not how you compete; the economics are not close.
- The spreadsheet joining two systems is usually the specification for what to build.
- Count the manual reconciliation work — it is the cost that never appears on an invoice.
- Changing your process to suit a tool is the clearest signal you have outgrown it.
- Building the connective layer is often better than replacing the tools.
The takeaway
Buy the commodity. Build the part that is genuinely yours, and only when the workarounds have started costing real time. If you are unsure which side of the line you are on, the spreadsheet everyone depends on usually settles it.
We build the connective layer more often than we build replacements — tell us what your spreadsheet does, or read how we scoped exactly this problem for services firms.