A software company telling you when not to build custom software may seem odd. But projects that should never have started are the ones that go badly, and they go badly for everyone involved. It is worth being clear about which situations genuinely call for it.
When you should not build
A ready-made product already fits
If a standard product covers your process at a monthly fee, buy it. Custom software is worth it when your process is a genuine advantage or genuinely unusual — not when you simply have not looked at what exists.
Your process is not settled yet
Building software freezes a process into code. If you are still changing how you work every few weeks, wait. Run it on spreadsheets until it stabilises, then build what has proven itself.
The problem is people, not tools
If staff do not follow the current process, a new system will not make them. Software enforces a process; it does not create the will to follow one. This is the most common reason projects are abandoned after launch.
You cannot name what success looks like
If you cannot say what should be measurably different in three months, the project has no finish line. It will expand until the budget runs out.
When you should build
Your process is a real differentiator
If the way you operate is why customers choose you, generic software will force you to work like everyone else. That is when custom is worth paying for.
You are paying people to move data between systems
Staff hours spent copying between tools is a cost that recurs forever and grows with the business. It is one of the easiest cases to justify, because the current cost is countable.
Off-the-shelf costs more at your scale
Per-user pricing that was cheap at five users can be significant at fifty. At some point the recurring fee exceeds the cost of owning something.
You need systems to talk to each other
Standard products rarely integrate the way a specific business needs. Connecting them properly is often a custom build regardless of what else you buy.
Compliance or reporting nothing supports
Industry-specific reporting that no product produces is a legitimate reason to build, because the alternative is doing it manually forever.
A decision test
- 1Write down the process, step by step, as it runs today.
- 2Count the hours it consumes each week and price them.
- 3Search seriously for an existing product. Spend a full day on this.
- 4If something fits at 80%, adopt it and change your process for the other 20%.
- 5If nothing gets close, and the counted cost is meaningful, build — but build the smallest version that fixes the worst part first.
Start smaller than feels right
The projects that succeed tend to start with one process, go live within weeks, and grow based on what the team learned using it. The ones that fail try to replace everything at once and are still not live a year later. If in doubt, cut the scope.
Want to talk through your own situation?
Book a free consultation. We will tell you what we would build, what it would take, and whether it is worth doing at all.