When Should a Business Build Custom Software?

Most software a business runs on should be bought, not built. Accounting, payroll, email, CRM, helpdesk — these are solved problems with mature products behind them, and a custom rebuild will almost always be slower, more expensive and worse. Any engineering firm that tells you otherwise is selling you something.

But there is a real category of work where buying fails, and businesses stuck in that category often spend years absorbing the cost quietly — in spreadsheets, in manual re-entry, in a process that only one person fully understands. The question is how to tell the two situations apart before committing budget.

Four signals that justify building

In our experience these are the conditions where custom software genuinely pays back. You do not need all four, but one on its own is rarely enough.

1. The process is your competitive advantage. If how you price, route, schedule or manufacture is a differentiator, standard software will force you to operate like your competitors. That is the strongest argument for building there is — and it applies to a narrow slice of what any business does.
2. The workflow spans tools that will not talk to each other. When staff spend their day copying data between three systems, the cost is not the licences. It is the re-entry time and the errors, and it compounds with headcount.
3. You are paying per seat for software you use 10% of. Large platforms price for their full feature surface. If you use a fraction of it and the licence scales with staff, the arithmetic can flip surprisingly early.
4. The constraint is regulatory or contractual. Data residency, audit trails, retention rules or a client contract that dictates how information is handled will sometimes rule out every off-the-shelf option outright.

Four signals you should not build

• "The existing tool is 80% right." Closing that last 20% with custom software usually costs more than the whole product did. Configuration, an integration, or changing the process is nearly always cheaper.
• Nobody can describe the current process end to end. If the workflow only exists in people's heads, building software will force you to define it — expensively, mid-project, under deadline. Define it first, on paper.
• The driver is a single frustrated stakeholder. Software built to settle an internal argument gets used by one department and abandoned.
• There is no budget for year two. This is the one businesses most often miss, so it gets its own section.

The cost nobody quotes for

A build quote covers getting to launch. It does not cover owning the result. Custom software is not a capital purchase that sits on a shelf — it is closer to hiring: there is an ongoing obligation, and if you stop meeting it the asset degrades.

Realistically, budget for infrastructure and third-party services, security patching of dependencies, operating-system and framework upgrades that arrive whether you want them or not, and a modest stream of changes as the business shifts. A common industry rule of thumb puts annual maintenance at roughly 15–20% of the original build cost. Treat that as a planning figure, not a quote — but a plan with a zero in that line is not finished.

The middle path most businesses actually need

The choice is rarely build-everything or buy-everything. The most cost-effective answer is usually to keep the commodity systems you already pay for and build only the thin layer that is genuinely yours — the workflow that sits between them.

That might be an integration service that moves records between two platforms on a schedule, a small internal tool that replaces a shared spreadsheet, or a customer-facing portal that reads from the system of record you already own. These projects are smaller, they carry far less risk, and they can be delivered in weeks rather than quarters. They also fail cheaply, which matters more than it sounds.

A test worth applying before you commit

Write down the process as it runs today, step by step, including the exceptions. Then estimate how many hours per week it consumes across everyone involved, and multiply by a year.

Two things fall out of that exercise. The first is a number to compare against a build cost. The second — more valuable, and free — is that roughly a third of the time the act of writing the process down reveals that the real fix is a policy change or a configuration setting, not software at all. That is a good outcome. It is considerably cheaper than the alternative.

If the number still justifies building after that, you have something worth quoting: a defined process, a measured cost, and a scope that stops somewhere.