Custom software or off-the-shelf: an honest comparison

Ask a software company whether you need custom software and you will usually be told yes. It is a larger project and a longer relationship. So it is worth setting out the case for the other answer properly, because for a good number of organisations the ready-made product is simply correct.

Off-the-shelf is usually right

A packaged product carries a lot of value that is easy to overlook because you do not see it being built.

• **It has been used by thousands of organisations.** The edge cases you have not thought of have already been hit, reported and fixed by somebody else.
• **It is available immediately.** No scoping, no build, no waiting.
• **The cost is known.** A monthly figure with no delivery risk attached to it.
• **Someone else maintains it.** Security patches, framework upgrades and browser changes are not your problem.
• **Support exists.** Documentation, a help desk and usually a community of other users.

If your requirement is something many organisations have — accounting, payroll, email, a standard shopfront — building it yourself means paying to recreate something mature and then paying again, forever, to maintain it.

The honest default is: try to use a product. Move on from that default only for a specific reason you can name.

The reasons that are actually good

Custom development earns its cost in a narrower set of situations than it is sold for.

**Your process is genuinely unusual and the difference is the point.** Not "we do it slightly differently" — every organisation believes that. Genuinely unusual: an examination system that has to follow one state board's specific evaluation rules; a subsidy workflow that follows a scheme's own approval chain. If the difference is where your value is, forcing it into a product's assumptions destroys the thing that made it worth doing.

**Integration is the requirement.** When the actual job is making four existing systems talk to each other, no product covers that. The integration is the software.

**The product exists but the economics do not.** Per-user pricing that works at 20 users can be indefensible at 2,000. This is worth modelling honestly, because the crossover point is often further away than it feels.

**You need to own it.** Government departments and institutions holding sensitive records frequently have requirements about data location, access and continuity that a hosted product cannot satisfy at any price.

**The product is 80% right and the missing 20% is the reason you are buying.** This is the most common genuine case, and also the most commonly misdiagnosed. Which brings us to the trap.

The trap: unusual versus undocumented

From the inside, a process that is genuinely unusual and a process that is merely undocumented look exactly the same. Both feel unique. Both resist being mapped onto a product. Both produce the sentence "our situation is different".

The difference is that one of them is a real business requirement and the other is an accident that has hardened over the years — a sequence of workarounds, exceptions and personal preferences that nobody has written down or questioned.

Building custom software around the second kind is expensive twice over. You pay to encode the accident, and then you pay again every time you want to change it, because now it is in code.

**The test:** ask someone to write your process down, end to end, in plain language, and then ask a person who does not do that job to follow it. Where the description breaks down, you have found something undocumented rather than unusual. Fix the process first. It is cheaper than any software, and it is the only way to know what you are actually asking for.

What the money looks like

Rough shapes rather than quotes, because the real figure depends entirely on scope.

• **Off-the-shelf:** a monthly or annual fee, roughly linear in users, effectively forever. Low commitment, no delivery risk, no asset at the end.
• **Custom:** a significant one-time cost, then a much smaller annual maintenance figure. You own an asset. You also own the responsibility.

Custom development pays for itself when the accumulated subscription overtakes the build plus maintenance — which for a large user count can be two or three years, and for a small one may be never.

Two costs are consistently underestimated on the custom side, so state them plainly:

• **Maintenance is not optional.** Budget for it annually from day one. A system nobody maintains becomes a liability in about two years.
• **Your own people's time.** A custom build needs decisions from the people who know the process, and they already have jobs. This is a real cost and it does not appear on any quotation.

The pragmatic middle

Most good answers are not at either end.

A product for the standard parts — accounting, email, payroll — and a custom layer only where the process genuinely differs. Or a custom system that integrates a product rather than replacing it.

The decision is not made once, either. Plenty of organisations correctly start on a product and correctly outgrow it four years later, and there is nothing wrong with a decision that was right when it was made and is no longer right now.

The question worth answering is not "custom or product". It is "which specific parts of what we do are genuinely ours, and which parts are the same as everybody else's?"

Answer that honestly and the software decision mostly makes itself.