The spreadsheet that quietly became a system of record

It never starts as a system. Someone builds a sheet to get through a busy fortnight. It works, so it survives the fortnight. A column gets added for the thing that went wrong in March. Someone writes a lookup against a second sheet. Two years later a named person opens that file every morning, and if they are on leave the process stops.

We get called about these often, usually phrased as a request to "build the proper version". Sometimes that is the right answer. Often it is not, and the honest conversation is about which one this is.

A spreadsheet is not a failure state

It is worth saying plainly, because the software industry has an interest in you believing otherwise: a spreadsheet is an extraordinarily good tool. It is fast to change, needs no deployment, and every person you hire already knows how to use it. A process that fits in one and is not causing pain does not need replacing because it offends an architectural sensibility.

The question is never "is this a spreadsheet". It is "what happens when this is wrong, and would we find out".

The five signals that actually matter

These are the ones we look for. Any one of them is worth a conversation. Three or more and the spreadsheet is already costing more than the replacement would.

• More than one person edits it, and there is no reliable way to see who changed what. Version history in a shared drive is not an audit trail — it tells you a cell changed, not why, and nobody reads it until something has already gone wrong.
• Someone retypes its contents into another system. Every manual re-entry is a guaranteed error rate and a guaranteed delay, and it is usually the clearest signal that two systems should be talking to each other instead.
• It has formulas nobody present can explain. The person who wrote the nested conditional has left. It still produces a number, that number still goes to a client or a regulator, and nobody can say with confidence what it means.
• It holds personal or financial data. The moment it does, you have obligations about access, retention and deletion that a file on a shared drive is poorly equipped to meet. This one moves to the top of the list regardless of the others.
• A mistake in it would not be caught. Not "has not been" — would not be. If the only control is that the person who maintains it is careful, you do not have a control.

If the only control is that the person who maintains it is careful, you do not have a control.

What we usually recommend first

Not a rebuild. The first move is almost always smaller and cheaper: work out which part of the sheet is load-bearing. Most of these files are eighty per cent reporting and twenty per cent the thing the business actually depends on. That twenty per cent is what needs to become real software — validation, a record of who changed what, and an interface that does not permit the mistakes the sheet currently allows.

The rest can stay a spreadsheet, and often should. People are quick in them, and replacing a flexible reporting layer with a rigid one is a common way to make a system that everybody works around.

The part people underestimate

The build is rarely the hard part. The hard part is that the spreadsheet encodes years of undocumented decisions — the exception for one client, the rounding rule somebody agreed verbally, the row that is always handled by hand. None of it is written down, and all of it has to be, because software will not quietly accommodate an exception the way a human with a cursor does.

Expect that discovery to take real time and to surface disagreements about how the process is supposed to work. That is not the project going badly. That is the project doing the thing it was worth doing for.

When to leave it alone

If one person maintains it, the data is not sensitive, an error would be obvious within a day, and the process is likely to change shape again within the year — leave it. Build the software when the process has stopped moving, not while it is still being argued about. Freezing a half-settled process into an application is how you end up with a system everybody resents and a second spreadsheet running alongside it.