Every software studio has a commercial incentive to tell you that you need custom software. We do too. This article exists because the incentive is worth resisting — a smaller honest engagement produces more referrals than a padded proposal, and a client who resents what they paid for tells more people than one who does not.
The test, in one question
Is there something about how your business works that no product anticipated?
Not "we do things our own way" — everyone believes that. Something specific and nameable:
- A pricing rule nobody else has. Slab rates that change mid-order, customer-specific rates negotiated per account, a unit of measure that converts partway through the process.
- A document only your regulator or your industry wants, in a format that must match exactly.
- A workflow that spans four roles and three systems, where the handoffs are the hard part.
- A data model the product simply does not hold — batch-level MRP in a pharmacy, per-shift reconciliation at a fuel station, volume-based quoting from a physical survey.
If you can name one of those in a sentence, custom is probably worth costing. If you cannot, keep reading, because the honest answer is likely to save you a lot of money.
Four cases where buying wins outright
Your process is standard and you just have not configured the tool
The most common case by far. A business buys a CRM, never maps their stages onto it, and concludes the tool is wrong. It usually is not — it is unconfigured. Two days of proper setup on something you already pay for beats eight weeks of building something new.
You need breadth, not depth
If you want marketing automation and sequences and a partner ecosystem and a mobile app and an integrations marketplace, buy the product that has all of them. A custom build gives you the twelve things you actually do, done exactly right. It does not give you a hundred things done adequately, and it never will at a price you would accept.
The domain is a compliance minefield you do not want to own
Payroll with statutory deductions. Full accounting with audit trails. Tax filing. These are heavily regulated, they change every budget cycle, and the maintenance cost of keeping up is real and permanent. Buy the product whose entire business is staying current, and integrate it.
The volume does not justify the build
A task that takes four minutes and happens twice a week is not an automation candidate. The same task sixty times a day is. Multiply honestly before you scope anything: minutes saved × frequency × the cost of the person doing it. If the payback is longer than about eighteen months, it is not a project yet.
Where custom genuinely wins
The tool enforces a process that is not yours
This is the failure mode that produces the private spreadsheet. Your team adopts the tool, discovers it will not let them record the thing they actually need to record, and starts keeping a sheet alongside it. Within a quarter the sheet is the real system and the software is a licence fee.
Custom does not mean better. It means the data model matches what is physically true in your business, which is what makes people use it.
You are paying per seat for something you use a tenth of
Twelve users on a per-seat product for four years is a large number. If you are using a fraction of the product, a one-off build you own often costs less than the licence over the same horizon — and the comparison should be made with actual numbers on a first call, not asserted.
The integration is the product
Sometimes you do not need new software at all: you need the six things you already run to stop needing a person as the connector between them. That is usually the cheapest project available and the fastest to pay back, and it is worth checking before anyone proposes a build.
How to have this conversation with a vendor
Ask three questions, and listen to how they are answered.
- 01"What off-the-shelf tool would do this, and why is it wrong for us?" A vendor who cannot name one has not looked.
- 02"What is deliberately excluded from this scope?" If the proposal has no exclusion list, the price is not fixed — the argument has just been postponed.
- 03"If we hired a developer next month, could they take over without calling you?" The honest answer requires code in your Git organisation, documented environment variables, a seed script and a runbook.
The uncomfortable conclusion
Most businesses that ask for custom software do not need it yet. What they need is one process digitised properly, or two systems connected, or an existing tool configured by someone who bothered to map their workflow first.
Those are smaller projects. They are also the ones that work.