Nearly every business we work with has one. A spreadsheet that runs something important, built by somebody good, and quietly load-bearing.
It might price the jobs, or forecast the month, or track the compliance dates. It has been through eleven versions, half the columns are hidden, and there is one tab everybody has learned not to touch. When we suggest replacing it, the room gets defensive, and they are right to be.
The spreadsheet is not the problem
The spreadsheet is evidence. It exists because a real need was not met by the systems the business bought, and somebody solved it themselves rather than waiting.
That is initiative, and the logic inside it is usually excellent. It encodes years of judgement about how this particular business actually works, which pricing rules apply to which customers, which exceptions matter. There is more institutional knowledge in that file than in any process document.
So the goal is never to delete it. It is to understand why it had to exist, and to notice what it now costs.
Three costs, and none of them are the licence
The first is the person. Usually one individual can genuinely maintain it. When they are on leave, the thing that spreadsheet does either stops or gets done badly, and nobody escalates because it is only a spreadsheet. If that file prices your work, one person's holiday is a commercial risk.
The second is silent error. Spreadsheets do not tell you when they are wrong. A formula gets dragged one row short, a filter stays on, a row gets inserted outside a range, and the output looks entirely normal. Systems have validation and audit trails. A spreadsheet has whoever last looked at it carefully.
The third is the ceiling. It works at your current size. At twice the volume it becomes slow and fragile, and the failure arrives during your busiest month, because that is when the volume is highest and the attention is lowest.
Why replacing it usually fails
Because people rebuild the visible part and skip the judgement.
The spreadsheet has forty rules in it. Thirty are obvious and documented in the formulas. Ten live in the head of the person who maintains it, applied by eye. Build the thirty and you have something that gets the easy cases right and quietly gets the profitable exceptions wrong. The team notices within a fortnight, goes back to the spreadsheet, and now you have both.
Getting those ten out is not a technical task. It is sitting with that person and working through the awkward cases until the reasoning is explicit. That takes hours, not minutes, and it is the actual work.
What we do instead
We treat the spreadsheet as the specification, because it is the best one available.
We work through it with the person who owns it, rule by rule, including the ones they apply without noticing. We map what feeds it and what depends on it, since that shows exactly where the real systems failed to connect. Then we build the logic into something with validation, history and no single point of human failure — and we keep the spreadsheet running alongside it until the numbers match for a full cycle.
Running both in parallel feels like duplicated effort. It is the cheapest insurance you will buy, and it converts the owner from a sceptic into the person who verifies it.
What to do this week
Find the spreadsheets that are load-bearing. Ask a simple question: if this file was gone tomorrow, and the person who maintains it was away, what would stop?
Anything with a real answer belongs on the list. Not to be deleted, but because each one is a precise map of somewhere your systems do not meet, drawn by whoever understands the problem best.
