The person who built your internal tool has just handed in their notice. They walk you through it for an hour, answer your questions, and leave. Three weeks later something breaks. Nobody knows where to look.
That is not a hypothetical. It is the exact shape of the call we get.
The tool is usually a spreadsheet, a Google Sheet with some scripts bolted on, or a low-code board that one sharp ops person configured over eighteen months and now lives inside their head. It works until it does not. And the cost of it not working is not a server bill. It is hours, decisions, and trust.
Three signs tell you the tool has crossed the break-even point. All three were visible in the operation we rebuilt VitalRegistry from.
Sign 1: One person can fix it. Everyone else works around them.
The original tracking system was Excel. Over ten rental devices per distributor, multiple versions of the same file, edits made in parallel with no merge strategy. The person managing it had built it herself. She knew which column took precedence, which formula to trust, and which tab was the actual source of truth.
That knowledge did not exist anywhere else.
The operational cost of that arrangement is not just a key-person risk in an HR sense. It is a bottleneck that compounds in real time. Every ambiguity routes back to the same person. Every "quick question" is a cognitive interruption on someone who is supposed to be running the business, not interpreting the tool.
The self-diagnostic: List the five most common questions your team asks about your tool. Count how many of them route to the same person. If three or more land in the same inbox, you have a load-bearing single point of failure.
Sign 2: Your team has built workarounds you do not know about.
This is the sign nobody names. It is also the most expensive one.
The spreadsheet breaks in a small way. A formula returns the wrong value for an edge case, a field does not quite capture the thing it needs to capture. The person who notices does not want to bother the builder, so they fix it themselves. They add a notes column. They copy data into a side sheet. They start a Notion page to track the exceptions.
Those workarounds work. That is the problem. They become load-bearing in the operation. The side sheet becomes the actual source of truth for that edge case, and nobody documents it because nobody thinks to. The original tool stays in place, nominally doing its job, while the real logic quietly migrates into artifacts the builder has never seen.
By the time you audit the tool, you are not auditing the tool. You are auditing the tool plus a shadow system of compensating behaviors that grew up around it.
The self-diagnostic: Ask three people on your team to walk you through one full operational workflow: rental out, rental back, contract sent, payment logged. Watch where they go when the tool is not sufficient. Every tab-switch to a different sheet, every "I keep track of that separately," every "we do not use that field, we use this one" is a load-bearing workaround.
Sign 3: Month-end reconciliation is a ritual, not a report.
Mum saves tens of hours a month with VitalRegistry compared to her spreadsheet workflow. The hours that used to go to end-of-month reconciliation now go to actually talking to clients.
That sentence contains the full cost model.
Reconciliation at the end of each month was hours of cross-referencing she did not have. Multiple file versions, entries that disagreed, no clear record of which update was final. The reconciliation was not a five-minute sanity check. It was a process.
Multiply that by twelve. Multiply it by the number of people who touch the tool. Add the decisions that did not get made because the data was not clean enough to trust, and the clients who got slower service because the person managing their account was reconciling instead of responding.
The rebuild cost, in time and engineering hours, is a one-time event. The reconciliation cost is a subscription you pay every month, with no upgrade path.
The self-diagnostic: Log the actual hours your team spends preparing data for use, rather than using it. Not the hours in the tool. The hours before the tool is trustworthy enough to act on. If that number is more than a few hours a month per person, run the annual projection. That number is your rebuild budget.
The principle
Internal tools do not fail loudly. They accumulate quiet costs: the workaround that became essential, the reconciliation that became ritual, the builder whose departure would ground the operation. Each cost is small enough to absorb in isolation. Together they exceed the cost of fixing the underlying problem.
The rebuild conversation is rarely about the tool. It is about the operation the tool is running under. The tool is just the clearest place to start.
A real question worth sitting with: If the person who built your internal tool left tomorrow, how long before your operations showed the gap?