Every consultant's instinct is to treat the spreadsheet as the villain. It usually is not. In most businesses we walk into, the spreadsheet is the single best-designed artifact in the building — somebody who actually does the work modeled their process in it, iterated on it for years, and got it right. It exists because it was faster than asking for software, and it survives because it works.
What happens is quieter than failure. The sheet accumulates responsibility until it stops being a document and becomes an application — one with no permissions, no history, no validation, and one person who understands the formulas. The question is not whether spreadsheets are bad. It is whether yours has crossed that line.
Six signs it has crossed the line
1. People coordinate about the file, not the work
"Are you in it?" "Can you close it, I need to update." Files named with _final, _final_v2, _FINAL_USE_THIS. Cloud spreadsheets solved simultaneous editing, but not simultaneous intent — two people editing the same row from different assumptions still produces one wrong answer and no record of the disagreement.
2. Access is all or nothing
The tell is a hidden tab, or a second copy of the sheet with columns deleted, sent to the people who should not see margins or salaries. Spreadsheets have no real row-level or field-level permissions. The moment a process needs one person to see their own records and another to see everything, you are maintaining copies — and copies drift.
3. Nobody can reconstruct what changed
Version history exists, but it answers "what did this cell used to say" rather than "who changed this order's status, when, and why". When a number is questioned three months later and the honest answer is "I think Dave updated it", the sheet is no longer a system of record — it just looks like one.
4. Validation is a suggestion
A date typed as text. A quantity with a stray space. A dropdown someone typed past. Each one is invisible until the pivot table silently excludes it and the monthly number comes out wrong. Spreadsheets validate on entry at best and never enforce relationships between rows.
5. It has become a program
Nested IF statements four levels deep, VLOOKUP chains across five tabs, a macro someone wrote in 2019, conditional formatting encoding business rules. This is software — written in the worst available language, with no tests, no code review, and no way to see the logic without clicking each cell. And exactly one person can safely change it.
6. Other systems depend on its shape
The moment something else reads that file — a report, an import, a script, another team's sheet — the column layout is frozen. You can no longer improve the thing without breaking something downstream. This is the sign that usually arrives last and hurts most.
What it is actually costing
| Symptom | What it really costs | Fixable in a spreadsheet? |
|---|---|---|
| Coordination about the file | Interruptions, and edits made from stale assumptions | Partly — cloud editing helps, intent conflicts remain |
| All-or-nothing access | Maintained copies that drift out of sync | No |
| No trustworthy history | Disputes that cannot be settled; audit exposure | No |
| Advisory validation | Silent errors in the numbers people decide on | Partly — validation rules catch some of it |
| Logic embedded in formulas | One irreplaceable person; changes nobody dares make | No |
| Frozen shape for downstream consumers | The process can no longer improve | No |
The pattern in that last column is the useful part. Two of the six genuinely can be improved without building anything — which is why the honest first step is not a rebuild.
Half-measures that are sometimes enough
- Put a form in front of the sheet. If most of the pain is bad data arriving from many people, a form that writes structured rows removes a surprising share of it for almost no cost.
- Lock the structure. Protect formula ranges and headers so only the data area is editable. This alone prevents the most common catastrophic accident, which is someone overwriting a formula with a pasted value.
- Split calculation from entry. One tab that people type into, one that computes, and never the same cell doing both.
- Move to a database-backed sheet product. There is a real category of tools between a spreadsheet and a custom app, and for a straightforward process with modest permission needs, one of them may be the whole answer.
We recommend these regularly, including when it means there is no project. If a process is genuinely standard and the pain is entry quality rather than logic or permissions, building software for it is the expensive way to solve a cheap problem.
When those are not enough
Half-measures run out when the process needs things a grid fundamentally cannot express: different people seeing different subsets of the same records, a state machine with ownership and handoffs, an audit trail that stands up to a question months later, or logic that has to run identically every time regardless of who opens the file.
They also run out when the sheet is the seam between systems. If its real job is to hold what your other software has no field for, then what you have is an integration problem in a grid costume — that pattern is covered in how to connect a legacy system to AI without replacing it.
The spreadsheet is the spec — read it before rebuilding
This is the part teams skip, and it is where most of the value is. That file encodes years of decisions that exist nowhere else. Before designing anything, go through it and extract:
- Which columns are actually filled in. The abandoned ones are requirements someone thought they needed and did not. Do not rebuild them.
- The conditional formatting. Every colour rule is a business rule someone cared enough to encode. Red usually means an exception the new system must surface.
- The comments and notes. These are the edge cases — the customer with different terms, the job that skips a step, the exception from three years ago that still applies.
- The tab everyone duplicates. If people copy a tab to start something, that is your create-new flow, already designed by its users.
- The manual step at the end. The thing someone does after the sheet is updated — send an email, update another system, tell a person. That is the automation with the clearest payoff.
A spreadsheet that survived five years of real use is a better requirements document than anything you would get from a workshop.
Keep the spreadsheet for what it is good at
Rebuilding the recurring process does not mean banning spreadsheets, and any proposal that implies it should be treated with suspicion. Ad-hoc analysis, one-off models, scenario work, scratch thinking — a grid is the right tool and always will be. What moves into an app is the process that repeats with the same shape every week.
The practical version of this: ship an export that looks like the old sheet. It costs very little and it does more for adoption than any feature, because the people who built their whole mental model around that layout keep it. It also gives everyone a way back if something is wrong in week one, which is what actually lets them commit.
Frequently asked questions
Is it always worth replacing a business-critical spreadsheet?
No. If the pain is mainly data-entry quality and the permission needs are simple, a form in front of the sheet or locked formula ranges may solve it entirely. Replacement makes sense when the process needs row-level permissions, a real audit trail, or logic that must run identically every time.
What usually goes wrong when a spreadsheet is rebuilt?
Rebuilding what the file shows instead of what people use. The abandoned columns get faithfully recreated while the conditional formatting rules, cell comments, and the manual step someone does after updating it — the parts that carry the real business logic — get lost.
Can we keep using spreadsheets afterwards?
Yes, and you should. Ad-hoc analysis and one-off models belong in a grid permanently. What moves into an app is the process that repeats with the same shape. We also ship an export matching the old layout, because it is the single biggest driver of adoption.
What about tools that are a database with a spreadsheet view?
They are a genuine middle option and sometimes the entire answer, particularly for a straightforward process with modest permission requirements. They tend to run out when you need complex role-based access, integration write-back, or logic that has to be reviewable.