Off-the-shelf software earns its keep. It is supported by someone else, updated without your involvement, and proven across thousands of businesses that look broadly like yours. For most processes, that is exactly the trade you want — and replacing a packaged product with custom code is usually the wrong instinct.
The difficulty is that a product rarely announces the day it stops fitting. The fit erodes quietly, one workaround at a time, until your teams are spending real effort working around the tool rather than working with it. By then the cost is spread across so many small frustrations that nobody has added it up.
A custom build is not a reward for outgrowing a product. It is a liability you take on deliberately, because the alternative costs more.
The signs a product is now fighting the business
None of these is decisive on its own. Taken together, they describe a tool that no longer matches how the business actually runs:
- Workarounds have become the process. People follow an undocumented sequence of steps the software was never meant to support, and onboarding a new hire means teaching the workarounds first.
- Shadow spreadsheets are doing the real work. The system of record says one thing; the spreadsheet the team actually trusts says another, and reconciling them is somebody’s recurring job.
- Every integration is a negotiation. Getting data between the product and your other systems means brittle exports, manual re-keying, or a connector that breaks whenever either side updates.
- The licence bill is climbing faster than the value. You are paying for seats, tiers, modules or add-ons to recover functionality that used to be standard, or to bolt on what the product cannot do natively.
- Reporting requires an export and a human. The numbers leadership relies on are assembled by hand outside the tool, which is usually why nobody fully trusts them.
When you should not build
Recognising the strain is not permission to commission a custom system. A build is a long-term commitment — you become responsible for maintenance, security, hosting and the institutional knowledge that a vendor would otherwise carry. Before going down that road, rule out the cheaper answers honestly.
Do not build when the packaged product can do what you need and the real problem is configuration or training. Do not build to encode a process that is itself broken; you will simply automate the mess. Do not build for a requirement that is genuinely common across your industry — that is precisely where a maintained product, or a well-chosen platform you extend, will outpace anything you write yourself.
The case for custom is narrow and specific. It holds when a process is a genuine differentiator for your business, when no product fits without contortion, or when the accumulated cost of licences, workarounds and integration glue has quietly overtaken what a focused build would cost to own.
Scoping a build so it stays maintainable
Most custom software does not fail at launch. It fails two years later, when the people who understood it have moved on and every change feels risky. That outcome is set during scoping, not coding.
Build the part that is genuinely yours, and buy or integrate the rest. Identity, payments, messaging and similar plumbing are solved problems; writing your own rarely pays back. Reserve custom work for the workflow that actually distinguishes you, and keep its boundaries with the surrounding systems clear and few.
Scope for the people who will inherit it. That means documented decisions, a test suite that lets the next team change things without fear, and dependencies chosen for longevity rather than novelty. A smaller system that one engineer can hold in their head will outlast a clever one that only its author understood.
- Write down why each major choice was made, not only what was built — the reasoning is what the next maintainer needs.
- Define the integration points up front and keep them stable, so the build does not inherit the brittle exports you were trying to escape.
- Ship a first version narrow enough to put in front of real users early, then extend from evidence rather than from a wish list.
- Plan for the handover from day one: access, runbooks, and a clear owner for the parts you did not write.
Making the decision in the open
The choice is rarely all-or-nothing. Often the right answer is to keep the packaged product for what it does well, retire the parts that have become a tax, and build only the slice that the business genuinely depends on. Custom software shaped around your processes earns its place when the off-the-shelf option has started bending the business to fit it.
We have lived this on both sides — stalled rollouts kept alive by spreadsheets, and builds that grew unmaintainable because their scope was never disciplined. If you are weighing the trade for a specific system, the useful first step is to add up the real cost of staying as you are, including the workarounds nobody counts. The honest number usually makes the decision for you.