When custom software is the right answer, and when it is not

Every growing business eventually hits the same wall: the tools that got it here no longer match how it works. The instinct is either to buy another subscription or to commission something custom. Both can be right, and the decision matters more than most people treat it.

Buy when the process is standard

If your process matches what the industry does, invoicing, payroll, a ticketing queue, a CRM, buy. Someone else has spent years on the edge cases, and you get their maintenance for a monthly fee. Custom software wins on fit, not on features, and fit is not worth paying for when the process is common.

Build when the process is the product

Custom software earns its place in a specific situation: the way you do the work is your advantage. A quoting model nobody else uses. A scheduling constraint that ordinary tools cannot express. A client portal that reflects your actual service, not a generic workflow.

The test is simple. If a competitor could adopt your process by buying the same tool, it is not custom-software shaped.

The three signals that it is time to build

1. The workaround has its own owner. Someone is employed, part-time, to reconcile between two systems.
2. The export is the process. Reporting runs on a spreadsheet that is assembled by hand from three sources every week.
3. The tool forces a worse process. Staff use the software in a way it was not designed for, because the designed way does not match reality.

If two of those are true, the cost of the workaround is usually larger than the cost of building the thing that removes it.

Scope it as the smallest useful release

The failure mode of custom software is not bad engineering, it is an over-large first release. Scope the one job the software must do well, ship it to the people who will use it daily, then extend along a backlog ordered by business value.

Design the data model and permissions before the first screen. Nearly every rebuild we are asked to quote traces back to a decision made about data and roles in the first fortnight of the original project.

What you should be able to demand

• A written scope, including what is out of scope
• Weekly, reviewable increments rather than one large reveal
• Documentation that lets a new engineer, yours or another firm's, take it over
• Clear ownership of the deliverables on final payment

Custom software is a long commitment. Buy it only where the fit genuinely pays, and insist on the terms that keep you in control of it.