It always starts neatly. Someone makes a spreadsheet to keep track of one thing, and it works. Then there is another column, another tab, a formula pointing at a different tab. Two years later the spreadsheet is the only place the most important information lives, and only one person understands how it fits together.
That is not a failure. It is the natural way systems come into being in a growing company. The question is not whether the spreadsheet was a bad idea — it was not — but when it stops being the right tool.
Four signs the time has come
The first sign is that more than one person needs to write to it at the same time. Spreadsheets are built for one author at a time, and anything beyond that ends in overwritten cells and wrong versions.
The second is that the spreadsheet is used from a phone in the field. It is technically possible, and it is always a poor experience. If your technicians or salespeople record things on the move, they deserve a tool made for it.
The third is that there are rules about who may see what — and they are enforced by sending different copies around. As soon as access control happens by duplicating the file, you have two truths.
The fourth is that one person has become indispensable. If only one person knows why column R shows what it shows, the spreadsheet is not a system. It is a risk with a date on it.
When it is fine as it is
If one person uses it, at a desk, and it works — leave it alone. We have declined to rebuild things because the problem was not big enough to justify the price. A spreadsheet doing its job is not a problem, it is a solution.
One person uses it
No conflicts over who writes what, and no versions living in separate places.
There are no access rules
If everyone should see everything, there is nothing to control. Then the file is fine.
It is used at a desk
A spreadsheet on a phone in a van is always a poor experience. At a screen it is fine.
The data is not critical
If the sheet were lost, it could be rebuilt in an afternoon. That risk is liveable.
What a rebuild takes
The most important part is not the code. It is putting words to the rules hidden in the formulas and in the head of the person who looks after the spreadsheet. We usually spend the first week on that alone, before anything is built. And the data already in the spreadsheet has to come along — an empty app is not a finished app.