Custom Software vs Off-the-Shelf: An Honest Framework

We build custom software, so treat what follows accordingly and then notice that the framework below tells a good number of people not to buy it. A project that should not exist is the most expensive kind of project, and it is worse for us than a declined enquiry, because it ends badly with our name on it.

The comparison almost everyone gets wrong

The usual analysis puts a build quote next to a subscription price: "£60,000 to build, or £400 a month for the product the build pays for itself in twelve years." Or, framed by a vendor with an interest: "£400 a month is £24,000 over five years, so building is obviously better."

Both are wrong, because a build cost is not a total cost. Custom software has an ongoing bill that starts the day it launches:

• Hosting and infrastructure usually modest, but never zero.
• Dependency and security updates. Software that is not maintained becomes a vulnerability, not a fixed asset.
• Bug fixes and support, including the hour someone spends explaining an edge case.
• Changes as the business moves which is the whole reason you built something specific in the first place.
• Key-person risk, unless the system is documented well enough for someone new to pick it up.

A realistic figure for maintaining a custom business application is somewhere between 15% and 25% of the original build cost per year. Any comparison that omits that line is not a comparison.

Compare five-year total cost of ownership on both sides. Build cost plus five years of maintenance and hosting, against subscription plus configuration plus integration work plus the staff hours currently spent bridging gaps.

When off-the-shelf is the right purchase

Buy when any of these are true, and buy without embarrassment:

• The process is genuinely standard. Payroll, accounting, email and core CRM are solved problems, and your version will not be better.
• A mature product covers 80% or more of the requirement without heavy configuration.
• The capability is a cost of doing business, not a differentiator. Nobody chooses you because of your expense-approval workflow.
• You do not have an ongoing budget for maintenance. Unmaintained custom software degrades into a liability within a few years.
• The product carries compliance certifications you would otherwise have to obtain yourself. That is often worth more than the software.

A vendor with a thousand customers has hit failure modes you would take years to discover, and has already paid for the fixes.

When custom is genuinely worth it

Build when one of these is clearly true:

• The workflow is the advantage. If what you do differently is why customers choose you, forcing it into a generic product erodes the thing that works.
• You are already paying for several tools plus the manual labour of moving data between them. That labour is the real cost and it rarely appears in anyone's comparison.
• Per-seat licensing has outgrown its value as you have grown, and the curve is going the wrong way.
• Your data is the asset and you need it in a shape no vendor exposes most commonly for reporting nobody's standard export supports.
• The integration and configuration work required to make a bought product fit is approaching the cost of building the specific part outright.

The answer is usually "both"

The framing as a binary is the deepest flaw in the whole debate. The right architecture for most businesses is to buy the commodity pieces, build the part that is genuinely yours, and integrate them properly.

A manufacturer might buy accounting, buy CRM, and build the quoting engine that encodes thirty years of knowledge about how to price a job because that engine is the business, and the other two are plumbing. The build is a fraction of the size of "a system to run the company", which means it can be delivered in months rather than years, and it fails in a contained way if it fails at all.

When someone proposes replacing everything with one bespoke platform, ask which parts of it are actually specific to you. The answer is usually a much smaller system than the one being proposed.

Questions to put to anyone quoting you

1. What will this cost to run and maintain per year after launch? A build quote without this number is incomplete.
2. Which existing products did you evaluate, and specifically why do they not fit? "They're not flexible enough" is not an answer.
3. What is the smallest version that delivers real value, and when is it in production? Anything with no working software for a year is a risk, not a plan.
4. Who owns the code, the infrastructure and the data? The only acceptable answer is that you do, from the first commit.
5. What happens if we want to move this in-house in two years? A good partner has a straightforward answer.

If a vendor cannot describe the circumstances under which you should not hire them, you are talking to a salesperson.