Systems
The spreadsheet
nobody is allowed
to touch.
Every business I work with has one. It runs a critical process, exactly one person understands it, and everyone else is quietly afraid of it. Here is what it really costs and how to replace it without breaking the week.
It is always the same discovery call. We are talking about a website or an app, and about forty minutes in someone mentions, almost as an aside, that the orders are tracked in a file. Then a slightly awkward pause. Then: it is a bit of a mess, honestly.
That file is usually the most important piece of software in the company, and nobody thinks of it as software at all.
Why it exists, and why it survives
It exists because it worked. Someone had a real problem on a real Tuesday and solved it themselves in an afternoon, without a budget, without a meeting, without waiting for anyone. That is an achievement and it deserves respect. Most internal tools sold for real money solve a smaller problem worse.
It survives for a better reason than inertia. It fits the business exactly, because it grew out of the business. Every strange column encodes a real exception that a real customer demanded in 2021. That accumulated knowledge is genuinely valuable, and it is the thing most replacement projects throw away in week one.
What it actually costs
The cost never shows up as a line item, which is precisely why it runs for years. It shows up like this.
- One point of failure, and it is a person. Maria built it. Maria is the only one who knows why row 340 must never be sorted. When Maria takes two weeks off, the process degrades. When Maria leaves, it stops.
- Nothing is validated. A date typed as text, a quantity with a comma instead of a full stop, a formula dragged one row short. The file does not complain. The error surfaces six weeks later in an invoice.
- There is no history. When a number is wrong, there is no way to find out who changed it, when, or what it was before. Every dispute becomes a matter of memory.
- Everyone sees everything. The file with the delivery schedule also has the margins in column R. So it gets copied, renamed, emailed, and now three versions exist and two of them are wrong.
- It cannot be connected. Not to the shop, not to the accounting software, not to a phone. So a human retypes the same data into a second system, every day, forever.
I once measured this properly for a distribution client. Two people spent roughly nine hours a week between them on retyping and reconciliation. Not a crisis, just a quiet leak. Over a year that is a full working month, spent on a task with no upside.
The file is not the problem. The fact that a critical business process depends on one person remembering the rules is the problem.
How to replace it without breaking the week
The instinct is to build the complete system. Resist it. Big replacements fail because the business cannot stop while you build, and because the old file has more edge cases in it than anyone can list in a meeting.
What works, consistently:
Start with the narrowest painful slice. Not the whole operation. The one step that generates the most retyping or the most errors. Ship that in two or three weeks so people feel it working before they have to trust it.
Read the file before you design anything. Not the summary of it, the actual file. Every hidden column and every conditional format is a requirement somebody forgot to tell you. This is the single highest value hour in the whole project.
Model the workflow that exists, not the tidy one. If orders sometimes arrive by phone and get entered the next morning, build for that. A system that only supports the official process gets abandoned in the first busy week.
Keep the export. People need to see their data in a familiar shape while they learn to trust the new thing. A clean export button removes most of the fear, and after two months nobody clicks it.
Put permissions and history in from day one. Who changed what, and when. It is close to free at the start and painful to retrofit. It is also the first thing anyone asks for the moment a number looks wrong.
The test that matters
There is one question I use to know whether the replacement actually worked, and it has nothing to do with features.
Can a new hire do the job correctly on their first day, without asking anyone?
If yes, the knowledge has moved out of one person's head and into the system, which is the entire point. If no, you have built a prettier spreadsheet, and in eighteen months somebody will be quietly afraid of that too.