When custom software actually beats off-the-shelf

Default to buying. Off-the-shelf software is maintained by someone else, and that is worth a great deal. But there is a point where the tool costs more than it saves, and it is usually visible in behaviour rather than in a spreadsheet.

We build custom software for a living and the advice still starts with “buy”. A vendor amortises their engineering across thousands of customers; you cannot beat that on cost for a problem you share with thousands of customers. The question is never “custom or off-the-shelf” in general. It is whether this particular process is one you share.

Signals that a custom build is cheaper

• A person’s job is moving data between two systems. That salary is a recurring licence fee for an integration nobody built.
• The real state lives in a spreadsheet. The tool is being worked around, so you are already paying for two systems.
• Per-seat pricing punishes the thing you want more of. Growth should not be a budget line.
• Your differentiator is the process itself. If how you do the work is the advantage, a template will flatten it.

Reading the signals honestly

The data-mover. Look at what the role actually costs, fully loaded, and how many hours go to transfer rather than judgement. Two days a week of a mid-level salary is a five-figure annual cost that recurs forever, against a build that is paid for once. But check the cheaper fix first: many of these roles exist because nobody has looked at whether the two systems have APIs. An integration is a fraction of the cost of a replacement, and it is the right answer more often than a build is.

The shadow spreadsheet. This is the strongest signal on the list, because it is evidence rather than opinion. Someone has already decided the official tool does not fit and has built the alternative themselves. Before concluding anything, find out which part is in the spreadsheet — it is rarely the whole process, and a custom layer over that specific part is usually cheaper than replacing everything around it.

Per-seat pricing. The pain is nonlinear and arrives suddenly. Note that it is not always a build signal: sometimes the answer is a different vendor, or fewer seats with better-defined roles. It becomes a build signal when the seats you cannot avoid are the ones growing — every field worker, every franchisee, every customer.

Process as differentiator. The hardest to judge, because every business believes its process is distinctive and most are not. A test that works: if a competitor adopted your exact process tomorrow, would they win more work? If yes, a generic tool that flattens it into standard stages is destroying the advantage you are paying to protect. If the honest answer is no, buy the tool and spend the money where the advantage actually is.

Signals that you should stay

• The process is genuinely standard — payroll, accounting, email.
• Compliance certification is the product, and re-certifying yourself is the real cost.
• Nobody internally will own the system after handover.

That last one is disqualifying on its own, and it is the reason most custom software fails. Not build quality — ownership. Software is not a purchase, it is a commitment: someone has to hold the credentials, decide about upgrades, and answer when it breaks. If nobody’s job description will contain that, buy the tool, because a well-built system with no owner becomes a legacy system in about eighteen months.

Two more worth adding. If the process is currently a mess, fix the process first — automating a broken workflow produces a faster broken workflow, and the build will absorb the blame. And if the requirement is still moving weekly, a configurable tool absorbs that churn more cheaply than a codebase does; wait until the shape has stopped changing.

What custom actually costs

Be clear-eyed about the whole number, because the build quote is not it.

The build is the visible part. Then: hosting and services, which for most business software is modest — often less than the licence it replaced. Maintenance, which is dependency updates, security patches and the small changes a working system always attracts; budget it as a recurring line rather than pretending the system is finished. And the migration itself — moving data, running two systems in parallel, retraining people — which is routinely underestimated and is frequently larger than the build.

Against that, what you stop paying: per-seat licences that scale with headcount, the salary of the person moving data between systems, the annual price rise you cannot negotiate, and the strategic cost of a vendor whose roadmap decides what you are able to do.

A middle path

Often the answer is neither: keep the SaaS product as the system of record and build a thin custom layer for the part that is specific to you. Smaller surface, less to maintain, most of the benefit.

This is the option teams forget exists, and it is right surprisingly often. Keep the accounting package; build the quoting tool that feeds it. Keep the CRM; build the technical qualification step it cannot model. Keep the ecommerce platform; build the inventory logic that actually matches your warehouse. You inherit the vendor’s maintenance burden for the commodity 80% and own only the 20% that is genuinely yours.

The risk to name up front: you are now coupled to the vendor’s API and their deprecation schedule. That is a real dependency, and it is usually a much smaller one than rebuilding their entire product.

How to decide in a week

Write down the process as it actually runs, including the exceptions people handle informally. Count the hours spent transferring rather than deciding. List the workarounds. Then price three options — the tool you have, a different tool, and a custom build or a thin layer over what you have — over three years rather than one, including the migration.

Most of the time that exercise says buy, or integrate. When it says build, it says so unambiguously, and you will have the numbers to defend it.

Sources and further reading

• Is high quality software worth the cost? — Martin Fowler
• Build vs. buy — Wikipedia