Nobody replaces a spreadsheet because it is bad. They replace it because it is load-bearing, and everyone has quietly noticed that it is load-bearing, and nobody wants to be the person holding it when it goes.
The interesting question is not whether Excel is the right tool. It obviously was, for years, which is why it is still there. The question is how to recognise the specific moment when it stops being an asset and becomes a liability — and what the first six weeks after that moment should actually look like.
Five signals, in the order they usually appear
These are the tells we see across freight, distribution, manufacturing and clinics alike. They arrive roughly in this sequence.
1. The file has a guardian
One person maintains it. They know which columns are formulas, which are pasted values, and which three rows near the bottom must never be sorted. When they take leave, a small amount of the business takes leave with them. This is usually the first signal and almost never treated as one, because the guardian is good at their job and the arrangement works.
2. Versions have started to travel
Dispatch_Sept_final_v3_REVISED(1).xlsx. Once a file is emailed or forwarded, there are two truths, and the reconciliation of those two truths is now a job somebody does. The cost is not the reconciliation. It is that during the window before it happens, people are making decisions from the wrong copy and nobody knows which decisions those were.
3. A second spreadsheet exists to check the first
This one is diagnostic. When you find a sheet whose only purpose is to verify another sheet, the operation has already conceded that its primary record is not trustworthy. Every hour spent in the checking file is an hour paid for the absence of a constraint.
4. The job posting
A company advertises for an MIS Executive — Advanced Excel, or a Reconciliation Assistant, or an Operations Coordinator with VLOOKUP in the requirements. That posting is a public statement that the process runs on spreadsheets and that the chosen remedy is headcount. It is also, read carefully, a fairly complete specification of the software that was not built. We wrote about that posting separately, because it deserves its own argument.
5. Month-end has a name
People refer to the last four days of the month as an event with its own character — a period to be survived rather than a date that passes. That is the accumulated cost of a month of small gaps, paid in one lump, by the people least able to refuse.
None of the above justifies a build on its own. Before spending anything, answer this: how many counterparties do you settle with every month?
Below roughly fifty, settlement is solvable from memory and a good spreadsheet, and software will feel like ceremony. Above about a hundred and fifty it is structurally impossible to do by hand and the only question is how much you are currently losing to that impossibility. In between is judgement — and is exactly where an audit is worth more than an opinion.
The mistake almost everyone makes next
Having decided to replace the spreadsheet, the instinct is to reproduce it. Same columns, same flow, same freedoms, now in a browser. This fails in a specific and predictable way: you have paid for software and kept every property that made the spreadsheet dangerous.
A spreadsheet’s defining characteristic is that any cell can hold anything. That is its genius for modelling something new and its fatal flaw for running something established. If the replacement preserves that freedom, you have rebuilt the problem with worse ergonomics.
The second mistake is scope by module. “We need a dispatch module, a billing module and a reports module” sounds like a plan and is actually a shopping list. Modules are how software is organised, not how an operation runs, and scoping that way guarantees the gaps between modules — which is where the money leaks — get specified by nobody.
What the first six weeks should look like
This is the shape of an engagement that works. We have run it enough times to be confident about the ordering, and the ordering is the part that matters.
Week 1 — find the real process
Not the documented one. Sit with the person who does the work and watch them do it, including the parts they apologise for. The exceptions are the system. A process description that has no exceptions in it is a description of a different company.
The output is a list of every state a unit of work can be in, and every event that moves it between states. For a freight broker that is a trip; for a clinic a patient episode; for a plant a batch.
Week 2 — write down what must always be true
Ten to thirty sentences, each of the form “it must never be possible to…”. It must never be possible to dispatch a trip with no vehicle assigned. It must never be possible for a bill to reference a trip that is already billed. It must never be possible to change a rate without recording who changed it.
This list is the most valuable artefact of the whole engagement, and it is free. It is also the one clients find most uncomfortable, because writing it down surfaces disagreements between departments that the spreadsheet had been quietly absorbing for years.
Week 3 — the schema, and only the schema
Entities, keys, relationships, and the constraints from week two expressed where they cannot be bypassed. No interface yet. This feels slow to everyone watching and it is the single highest-leverage week in the project — a wrong schema is paid for every month afterwards, and an interface is comparatively cheap to change.
Weeks 4 to 6 — the narrowest path that carries real work
One complete path, end to end, that a real person can use for real work on day one: create, progress, produce the document, settle. Not a demo, not a prototype — a path narrow enough to finish and complete enough to be used in anger.
Then run it in parallel with the spreadsheet for two weeks, deliberately, and treat every divergence as a finding rather than a bug. Divergences are where the written-down process and the actual process disagree, and you want to discover that while the spreadsheet is still there.
On timelines
A working system for an operation of this kind is a matter of weeks, not quarters. We built a freight broker’s entire operational system in twenty days — trip lifecycle, challan extraction, pump-credit reconciliation, customer and owner billing, and a tamper-proof audit log.
That is not a claim about heroics. It is a claim about scope discipline: twenty days was possible because weeks one and two had produced a list of states and a list of prohibitions, so there was nothing left to discover during the build. Projects do not usually overrun because the code was slow. They overrun because the decisions had not been made and got made, expensively, in the middle.
What to do with the spreadsheet afterwards
Keep it. Read-only, dated, archived. It is the record of how the business ran before, and for the first year the honest answer to some questions will be in it.
What must not survive is the habit — the parallel file that quietly reappears within two months because the system did not handle a case somebody needed handled. That file is not a workaround. It is a defect report, and the right response is to fix the system so that nobody needs it, not to tolerate it until it has a guardian of its own.