Four reasons to stop
- A product covers most of it — buy it, build only the gap
- The process is about to change — you would be encoding something you are discarding
- Nobody will maintain it — an unmaintained application becomes a liability
- The volume cannot repay it — do the arithmetic before going further
The right question is not whether a product does everything. It is whether the gap costs more than a build plus three years of maintenance.
Do the arithmetic honestly
- Frequency multiplied by time multiplied by hourly cost
- Plus error costs where they are real and countable
- Against build plus three years of hosting and maintenance
- Counting only time that would actually be redeployed
- Being conservative on saving and generous on cost
What to do instead
| Situation | Better answer |
|---|---|
| A product covers 80% | Buy it, build the integration |
| Spreadsheet works but is fragile | Move it to a cloud spreadsheet with validation |
| Data re-keyed between systems | An integration, not a new system |
| Reporting is manual | Automate the report, not the process |
| Process genuinely unclear | Document it first, then decide |
The maintenance question
An application nobody maintains becomes a liability within two years: unpatched, unchanged, and increasingly divergent from how the business actually works.
If you cannot name who will own it and who will maintain it, resolve that before commissioning anything.
We say this reasonably often
Recommending against a build loses us work and it is the correct answer often enough that we make it a habit.
A system that cannot pay for itself damages the relationship, the reference and eventually the client's appetite for any technology project.