Direct answer: Custom software is the wrong answer when an existing product adequately covers the workflow, the underlying process is still broken, the gap is temporary, the current spreadsheet is genuinely sufficient, or the business cannot support ongoing hosting, maintenance and security attention.
A build is not neutral
Custom software can fit a business closely, but that fit has a price beyond the initial project. The software has to be hosted, monitored, secured, maintained and changed as the business and its surrounding systems change. Someone must remain accountable when it fails.
That is worthwhile when the workflow matters and no adequate product fits it. It is poor value when the business is using a build to avoid a simpler decision.
Five times you should not build
An adequate product already exists
An existing product does not have to match every preference. If it handles the important workflow safely and the business can adapt around its limits, buying is usually the more responsible option.
The process itself is broken
Automating a confused process makes the confusion run faster. If nobody agrees who approves work, what information is authoritative or when a hand-off is complete, resolve those decisions before encoding them.
Nobody can own the software after launch
A build creates an asset and an obligation. If the business cannot resource hosting, maintenance, security attention and support — either internally or through a partner — it is not ready to own custom software.
The gap is temporary
A short-lived contract, transition or regulatory change may not justify software that outlives the need. A controlled manual process can be the better engineering decision.
The spreadsheet is actually fine
Spreadsheets are not automatically a problem. If one person owns it, the logic is understandable, access is controlled and its scale is stable, replacing it may add more overhead than value. Build when the spreadsheet has become a shared operational system it can no longer safely be.
The ongoing costs are operational, not just technical
Owning the code gives a business control. It does not remove these obligations.
- 01Hosting: the application needs reliable infrastructure and an owner for service interruptions.
- 02Maintenance: browsers, devices, libraries and connected systems change even when your workflow does not.
- 03Security: access, data protection, dependency updates and incident response need continuing attention.
- 04Support: staff need a path when a record is wrong, an integration fails or an exception was not anticipated.
- 05Change: the business will ask the software to evolve. Changes still need definition, testing and controlled release.
Questions to ask any software vendor
- 01When is custom software the wrong answer? Listen for a concrete answer, not a quick pivot back to the sale.
- 02What existing products or configuration paths have you ruled out, and why?
- 03Which part of our workflow is valuable enough to justify custom ownership?
- 04What will still be manual after launch?
- 05Who will host, monitor, secure and maintain the software?
- 06How do we keep the discovery outputs if we decide not to build?
Example: do not automate the approval argument
A project team asks for an approval application because work repeatedly stalls. Interviews show that the delay is not caused by missing software. Managers disagree about who has authority at different values, and staff submit incomplete information because no standard exists.
Building immediately would freeze the disagreement into screens and rules. The better first step is to agree the decision policy and trial it with a simple form. Only after the process works is it worth deciding whether configuration in an existing system is enough.