If a product does most of it
Building your own version of something available as a subscription is the most reliable way to spend a large sum reproducing something worse.
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.
Four reasons to stop
- A product covers most of it — buy it, and 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 the conversation goes further
Do the arithmetic honestly
Frequency multiplied by time multiplied by hourly cost gives you the annual cost of the current process. Compare that against build plus three years of maintenance and hosting.
- If it does not clear comfortably, do something else
- Count only time that would actually be redeployed
- Include error costs where they are real and countable
- Be conservative on the saving and generous on the cost
What to do instead
| Situation | Better answer |
|---|---|
| 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 whole process |
| Process is genuinely unclear | Document it first, then decide |
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.