Custom Software vs Off-the-Shelf: How to Decide Honestly

The honest starting position

We build custom software, so treat our view with appropriate suspicion — and then check the reasoning, because we turn down custom projects that should not be custom.

If a well-supported product does most of what you need, buying it and configuring it well is faster, cheaper and lower risk. You get years of accumulated features, other people's bug reports already fixed, and a supplier whose survival does not depend on your one project.

Custom development earns its cost in specific circumstances. Knowing which they are is the whole decision.

Where off-the-shelf wins

• Your process is conventional — standard retail, standard bookkeeping, standard payroll
• You need it working next month, not next quarter
• The budget is small enough that a custom build would be a compromised version
• The domain has heavy compliance requirements a specialist product already handles
• Nobody in your organisation has time to make decisions about screens and workflows

Where custom wins

• Your process is genuinely unusual, and every product forces expensive workarounds
• The thing you would customise is the thing you compete on
• Per-user licence fees across a growing team have overtaken a one-off build
• You need integration between systems no product connects, and manual bridging is costing real hours
• Data ownership or hosting location is a hard requirement, commercial or regulatory
• You have tried three products and each failed on the same specific gap

The cost comparison people get wrong

Off-the-shelf is usually cheaper in year one, sometimes dramatically. The comparison changes over three to five years and with user count.

Count on the product side: subscription per user per month, escalating over time; implementation and configuration; integration or middleware costs; the cost of processes you change to fit the software; and the cost of features you pay for and never use.

Count on the custom side: the build; hosting; maintenance and support; the internal time spent making decisions during discovery and testing; and the risk premium, which is real — custom projects can overrun, and an honest comparison prices that risk rather than ignoring it.

Do that arithmetic over the horizon you actually plan for. Many businesses discover the answer flips at around year three, and some discover the product was the right call all along.

The middle path most people miss

The choice is rarely binary. Three hybrids work well in practice.

Buy the commodity, build the differentiator: use a standard accounting package and build the operational system that is specific to your trade, connected by an integration.

Buy now, build later: adopt a product to start trading, and build once you know from experience which constraint actually costs you money — a far better brief than a guess.

Build one module: keep everything else and replace only the part causing pain, which is often a small, well-defined project rather than a system rebuild.

Four questions that usually settle it

Can you name the specific thing no product does? If not, you probably want a product, better configured.

Would you still want that thing if it cost three times your estimate? If not, it is a preference rather than a requirement.

Who on your side will make decisions weekly for the duration of a build? Custom projects fail on absent decision-makers more often than on engineering.

What happens if the supplier disappears? For a product, you migrate. For custom, you must own the source code and repository — which is why we transfer both on final payment.

How we handle this conversation

In discovery we will tell you if a product fits you better, and name it. That costs us the project and saves you a year, and we would rather have the reputation than the invoice.

Where custom is right, our software development page describes how we scope and build it, and the cost guide explains what actually moves the number.