In Kingdom, a good officer commands a hundred men by voice. He sees them, he knows them, he corrects in real time. The same officer at the head of ten thousand sees nothing. It isn't that he got worse: the tool that worked — his voice — no longer carries.
A spreadsheet is that voice. Formidable at small scale. And there is a precise moment when it stops carrying.
I built an app that replaces a timesheet spreadsheet for computing working hours. Before writing it, I spent time understanding why the spreadsheet had lasted so long — and what had finally broken.
First, in defence of the spreadsheet
A developer's reflex, facing a business-critical Excel file, is contempt. That's a mistake, and it costs engagements.
A spreadsheet that has run a business for four years is four years of business rules discovered and encoded. Every odd column corresponds to a real problem. Every sprawling formula is a decision taken on a day when something didn't work.
It's also, honestly, a remarkable tool: no installation, no training, editable by the person who needs it at the moment they need it. No bespoke software offers that.
So the right question isn't "how do we replace this spreadsheet". It's "is this spreadsheet still the right tool?" — and the answer is often yes.
The six signals
Here's what says you've passed the tipping point. One alone isn't enough. Three, and it's decided.
1. Several people need it open at once
You recognise the symptom: schedule_v4_FINAL_fixed_JP.xlsx. Or the person asking in the group chat whether they can open the file.
A spreadsheet is designed for one author. The moment two people write, you've invented a conflict-resolution system based on politeness.
2. You spend more time correcting than deciding
The monthly calculation takes an afternoon. Not because the arithmetic is long: because you first have to find the typos, the duplicates, the row shifted by one.
If cleanup time exceeds analysis time, the spreadsheet has become the work instead of serving it.
3. An error costs real money
A wrong cell in a prospect tracker is annoying. A wrong cell in a salary calculation is an underpaid employee and an unpleasant conversation.
As soon as the spreadsheet touches payroll, invoicing or sellable stock, the bar changes. Software validates on input; a spreadsheet accepts anything.
4. You can't answer "why this number?"
Three months later, someone disputes a figure. You open the file. The formula has been changed since. The source data has been overwritten.
A spreadsheet has no usable history. You can neither reconstruct nor prove. This is the most serious signal on the list, and the most often ignored.
5. Only one person can run it
She built the file, she knows the hidden tabs, she knows to refresh in that order. She goes on leave, and the business slows down.
That isn't a spreadsheet problem, it's a risk problem. But the spreadsheet made it possible.
6. You copy between files
Export from the time clock into one file, copy into a second, result into a third. Every copy-paste is a chance to get it wrong, and nobody keeps track of who copied what.
What NOT to do
Here's where most of these projects fail: reproducing the spreadsheet identically in software.
The client asks for it — it's reassuring, they know it. The developer accepts — it's specified, it's easy to quote. And you ship an app that does exactly the same thing, more rigidly, without the flexibility that made the spreadsheet bearable.
Users go back to the spreadsheet within three weeks.
What to do instead: take on only the knot of the problem. On the timesheet project, the pain wasn't "having a table". It was computing hours from a raw time-clock export, with the awkward cases — missing punch, shift crossing midnight. The rest — browsing, filtering, exporting — Excel already does very well.
So the application imports the XLSX, computes, and exports back to Excel. We didn't chase the spreadsheet out: we took away the one thing it did badly.
Monthly processing went from an afternoon to a few minutes. And nobody had to unlearn anything.
The right order, if you decide to go
- Keep the spreadsheet in production throughout the migration. It's your safety net.
- Automate one calculation, the most painful one. Nothing else.
- Compare both results for a month. The discrepancies you find are business rules nobody told you about — the most valuable part of the project.
- Add data entry only once the calculation is reliable and accepted.
- Never drop Excel export. Your users will always need it, and taking it away is the fastest way to lose their trust.
This order has a decisive advantage: value arrives in week two. A full rebuild needs six months before the first visible benefit, and often fails before that.
The underlying problem
Our profession has a bias: we like building, we don't like understanding what exists.
So we propose replacing where we should augment. We call "technical debt" a system that has worked for four years and keeps a company alive. We confuse "I don't understand this file" with "this file is bad".
Yet most SMEs, here and elsewhere, run on spreadsheets. That isn't a backward state to be corrected, it's a solution that worked up to a certain size. The useful work is finding precisely where it stopped working, and intervening only there.
The rest is sales.
The timesheet application is described here and is live. If you have a spreadsheet that's grown too heavy and you want to know whether you really need to leave it, write to me — sometimes my answer is no.