Most of the software a business runs on should be bought, not built. That is an odd thing for a custom software company to lead with, but it is the position that keeps our clients out of trouble — and it is the first thing we test in any engagement. A build we talk you out of costs you nothing. A build you should not have started costs you for years.
Here are the four situations where our answer is usually “don’t”.
1. The process isn’t settled yet
If the way you do the work changed twice this quarter, software will not stabilise it — it will freeze whichever version happened to be current on the day we started. Custom software is a bet that a process is worth cementing. Make that bet on a process you have actually run for a while, not on one you are still arguing about internally.
What to do instead: run it manually, or in a spreadsheet, until the exceptions stop surprising you. The exceptions are the specification.
2. An off-the-shelf tool already covers most of it
If an existing product does 80% of the job, the question is not whether the missing 20% is annoying. It is whether that 20% is worth owning forever — the maintenance, the upgrades, the person who understands it, the risk when they leave.
Often the honest move is to buy the tool and build a small integration around the gap, rather than replace a product someone else maintains for you. We have recommended that more than once on projects we would have been happy to build.
3. Nobody inside the business will own it
Every custom system needs an owner: someone who decides what it should do next, who fields the questions, who notices when it stops matching reality. If nobody has that job, the software drifts out of use within a year or two and becomes the legacy system somebody else has to replace later.
This is not a technical requirement. It is the single most reliable predictor we have seen of whether a build is still valuable three years on.
4. The real problem is the workflow, not the software
A surprising share of “we need a system for this” turns out to be “two teams disagree about who owns this step”. Software will not resolve that. It will encode the disagreement and give everyone a new thing to blame.
Worse, automating a broken process makes it break faster — which is a large enough problem that we wrote about it separately.
So when should you build?
When the process is genuinely yours, stable, and a real source of advantage. When no product fits without bending your operation out of shape. When somebody will own it. And when the cost of the status quo — the manual hours, the errors, the things falling through the cracks — is bigger than the cost of building and running the thing.
That is a smaller set of situations than most agencies will admit. It is also where custom software is genuinely transformative, which is why we would rather spend our time there.
How we decide
We map the workflows end to end, identify where regulated or sensitive data enters and leaves, and cost each option honestly — buy, integrate, automate, replace, or build. Sometimes the output is a build plan. Sometimes it is “buy these two products and connect them”. Either way you get a written answer you can take to anyone, including a different firm. That is the readiness audit.