Custom software vs off-the-shelf: how to decide

Start with off-the-shelf, and only build custom when you can name the specific thing it cannot do. Existing software is cheaper, available immediately, maintained by someone else and improved without you paying for it — which means the burden of proof sits with the custom option, every time.

That said, "just use a SaaS tool" becomes bad advice at a predictable point: when the workarounds stop being minor, when per-seat pricing outgrows the value, or when the process the software is bending is the thing your business actually competes on. This post is about recognising that point rather than guessing at it.

What off-the-shelf actually gives you

• It exists today. You can trial it this afternoon rather than waiting for a build.
• Someone else carries maintenance, security patching and compatibility with everything it integrates with.
• The cost is predictable and spread out, which is easier on cash flow than a capital project.
• It improves without you commissioning anything, because the vendor is selling to thousands of businesses with overlapping needs.
• Other people know how to use it, so hiring someone already familiar with it is possible.

None of that is trivial. A great many custom builds exist because nobody seriously evaluated the alternatives first, and they are a permanent tax on the business that commissioned them.

The five signals that custom is justified

These are the situations where building genuinely beats buying. If none of them applies to you, buy.

• The process is your differentiator. If how you quote, schedule or fulfil is a real competitive advantage, software that forces you into a generic version of it erodes exactly the thing you are good at.
• You are paying for workarounds. Count the hours your team spends exporting, re-keying, reconciling between two systems or maintaining a spreadsheet that shadows the real tool. That is a recurring cost, and it is usually invisible because it is spread across people rather than showing up on an invoice.
• Per-seat pricing has outgrown the value. Subscription costs scale with headcount whether or not the extra users need the full product. At a certain team size the arithmetic changes.
• You need two systems to talk and they will not. If the integration you need does not exist and the vendors have no interest in building it, you are stuck paying people to be the integration.
• You cannot get your data out. A tool that holds your operating history hostage is a strategic risk regardless of how well it works day to day.

The middle option most people miss

The choice is rarely binary. The most cost-effective answer is often to keep the off-the-shelf tools that work — accounting, email, payroll, document storage — and build only the one workflow that is genuinely yours, wiring it into the rest through their APIs.

That gives you custom where it matters and vendor-maintained software everywhere it does not. It is a much smaller build than replacing everything, and it avoids the classic failure where a business spends heavily to rebuild solved problems like invoicing.

A second middle option worth knowing: automation. Sometimes the real problem is not that your tools are wrong but that moving information between them is manual. Connecting existing systems is far cheaper than replacing them, and it removes the same hours.

The question of fit, and the 80% trap

Most evaluations end with a tool that fits about 80% of the workflow, and the decision turns on what the missing 20% actually is. This is where the choice is usually made badly, because 20% sounds small.

If the gap is spread thinly — a field you do not use, a report formatted differently, a screen with clutter on it — adapt and move on. Habit is not a requirement, and a great deal of "the tool cannot do it" turns out to mean "the tool does not do it the way we did it before".

If the gap is concentrated in one step that runs many times a day, the arithmetic is completely different. A missing capability in a workflow your team performs fifty times a week is not 20% of the problem; it is most of the cost, because every one of those runs now needs a human to bridge it. The question is never what percentage fits. It is how often you touch the part that does not.

The honest costs of building

• You now own maintenance forever. Dependencies age, platforms change, browsers update. Budget for it deliberately.
• No feature arrives unless you pay for it. There is no vendor roadmap quietly adding things.
• Bus factor. If one person understands the system and leaves, you have a problem. Documentation and clean handover are not optional extras.
• Time to value. Buying is instant; building is not. If the pain is acute right now, a stopgap tool while a build happens is often the right call.

A decision you can actually run

Write down the workflow end to end. Trial the two or three best-known tools against it for a fortnight — properly, with real data. List precisely where each one fails. If the failures are cosmetic or a matter of habit, buy and adapt. If the failures are structural, and you can estimate the hours the workarounds cost every month, you have both the justification for a build and the scope for it.

That list of structural failures is the most valuable document in the whole decision. It is also, conveniently, most of a specification.

If you have reached that point and want the workflow mapped before anyone writes code, our custom software development service starts with exactly that scoping step — and it is a step that occasionally ends with us telling you to buy something instead.