Almost every advisory firm has one. It started as a workaround and now three processes depend on it.
A system does not do something. Someone builds a spreadsheet to bridge the gap. It works.
Then a process depends on it. Then a second one. Then it is load-bearing and one person understands it.
Not the building. The maintenance, the key-person risk, and the fact that it exists outside every system that gets backed up, supervised, and reviewed.
When the person who built it leaves, the firm discovers what it was doing.
When the thing is specific to how your firm works and no product addresses it. When it is small and stays small. When it does not hold data that matters.
Plenty of good internal tools meet all three. The problem is the ones that stop meeting them and nobody notices.
Nothing is a temporary workaround after its second year.
If this stopped working tomorrow morning, what would break, and who could fix it?
If the answer to the first is "several things" and to the second is one name, you have infrastructure, and it should be treated as infrastructure.
Inventory them. Document what each does. Make sure someone other than the author can operate it. Decide deliberately which to replace and which to keep.
Keeping it is a legitimate decision. Keeping it accidentally is not.
Building because a vendor is frustrating. That produces something you now maintain, alongside the vendor you still pay, and a new seam between them.
Read next
The seams between your systems →