Spreadsheets are one of the most successful pieces of software ever made, and the reason this problem is difficult is that they are genuinely good. They are immediate, they need no project, and someone who understands the business can build something useful on a Tuesday afternoon without asking anyone's permission. Most business software could learn from that.
So the failure, when it comes, is not that the spreadsheet was a bad idea. It is that the thing which started as a personal working aid quietly became a system that other people, and eventually the business, depend on. Nobody decided that. It happened one column at a time.
The difficulty is recognising the point where it has happened, because there is no alert. The spreadsheet keeps opening.
Six signals
Each of these has a version that is fine and a version that is a warning. The difference is worth being honest about.
One: more than one person needs to edit it at the same time
The signal that arrives first and is dismissed the longest. It shows up as version confusion, as do not edit, I have it open, or as a shared file where two people's changes overwrite each other in ways nobody notices for a week.
Cloud spreadsheets handle simultaneous editing far better than files passed around by email, and for a small team that solves it for a long time. What they do not solve is two people making contradictory decisions at once: both allocating the same stock, both assigning the same slot. Concurrent editing is a formatting problem; concurrent decisions are a business problem, and a spreadsheet has no way to prevent them.
Two: one person is the system
There is someone who knows why the numbers in column M are hard-coded, which tabs are live, and which of the four copies is real. If they are on leave, changes wait.
This is the risk that costs the most and appears in no report. Ask a simple question: if this person left tomorrow, how long until someone else could safely make a change? If the answer is measured in weeks, the spreadsheet is a dependency the business has taken on without noticing.
Three: the copies have multiplied
Schedule_final_v3_new.xlsx, plus the one on the shared drive, plus the version someone downloaded to work on at home. When people ask which copy is current, the file has stopped being a source of truth and become a set of competing claims.
Four: nobody can tell who changed what, or when
Version history in a cloud spreadsheet gives you some of this. What it does not give you is a business-level record: this order was approved on Tuesday, by whom, from what previous state. When a customer disputes something, or an auditor asks, the honest answer is that the figure changed at some point and nobody can say why. For anything involving money, entitlements or compliance, this is the signal that should move fastest.
Five: correctness depends on people remembering
The rule is that column H must be filled in when column G says "dispatched", and that discounts above a threshold need a manager's approval. The spreadsheet does not enforce either. It relies on everyone remembering, every time, including during the busy week when a temporary member of staff is helping out.
Data validation catches some of it. The rules that cannot be enforced are the ones that depend on a state or a role: allowed now but not later, allowed by this person but not that one. A spreadsheet has no concept of who is looking at it.
Six: it has become an interface for other people
The clearest signal of all. When a spreadsheet is being sent to customers, or used to answer their questions, or copied into invoices and reports by hand, it has stopped being an internal working tool. It is now part of how the business is delivered, and it is carrying that responsibility without any of the properties you would ask of software doing that job.
What each signal actually risks
| Signal | The real risk | Cheapest next step |
|---|---|---|
| Concurrent editing | Two contradictory decisions, discovered late | Cloud spreadsheet with clear ownership of rows or sections |
| One person is the system | Operational stop when they leave or fall ill | Document it, train a second person, this week |
| Multiplied copies | Decisions made from the wrong version | One canonical location, access-controlled, others deleted rather than archived |
| No record of changes | Disputes you cannot settle, audit exposure | If money or entitlements are involved, this is the signal that justifies moving |
| Rules relying on memory | Errors that appear as customer problems | Validation where possible; otherwise a checklist with an owner |
| It is an interface for others | Business risk carried by a file | Extract the customer-facing part first, leave the rest as it is |
The last row is the most useful piece of advice in the article. When a spreadsheet has become customer-facing, the highest-value move is usually to replace only that part and let the internal working file continue exactly as it is. That is a small project rather than a large one, and it removes most of the exposure.
What to try before custom software
Custom software is not the next step after a spreadsheet. It is one of four, and it is the most expensive.
Fix the spreadsheet properly. Frequently underrated. One canonical file, one owner, validation on the columns that matter, protected formula ranges, calculation separated from data entry, and a written note of how it works. A day of that resolves a surprising number of these situations for another two years.
Move to a database-style tool. The category that sits between a spreadsheet and custom software: shared tables with defined field types, views, forms for entry, permissions and basic automation. For internal processes with modest logic and a handful of users, these are often exactly right, and they preserve what people liked about the spreadsheet. Two things to check before committing: what happens when your rules outgrow what the tool can express, and how you would get your data out if pricing changed.
Buy something built for the job. If the process is scheduling, inventory, project tracking or recruitment, established products exist and will be cheaper than building. The reason to reject them should be a specific mismatch, not unfamiliarity. Build or buy covers how to judge that properly.
Build something. Justified when the process is genuinely yours, when several systems must agree, or when the rules are too specific for a configurable tool. Even then, build the smallest piece that removes the risk rather than replacing the whole spreadsheet at once.
The trap worth naming: businesses often go straight from a spreadsheet to a full custom system, replacing five years of accumulated logic in one project. That is the most expensive and least certain route available, and much of the accumulated logic turns out to be either obsolete or wrong.
What spreadsheets remain better at
Not everything should move, and pulling the wrong things into software makes people worse off.
Modelling and analysis. Trying scenarios, testing assumptions, building a forecast. Spreadsheets are excellent at this and purpose-built software is usually worse, because the point is flexibility.
One-off work. A comparison for a decision next month. Building software for something used twice is waste.
Thinking. The first version of a process is frequently best worked out in a spreadsheet, precisely because it can be changed in seconds. Working it out there and then building the settled version is a good sequence.
The distinction that holds: spreadsheets are strong where the shape changes and weak where the data must be reliable over time. Analysis moves; records must not.
An illustrative example
A services company schedules 200 jobs a week in a shared spreadsheet. Two coordinators maintain it, engineers phone for their next job, and customers phone to ask when someone is coming.
Five of the six signals apply. The instinct is a full scheduling system covering allocation, engineer app, customer notifications and reporting.
Sorted by risk rather than by ambition, the picture changes. The largest exposure is not scheduling; it is that customers are being answered by two people reading a file, which is signal six. The second is that one coordinator understands the allocation rules and the other follows them. A first project that gives engineers and customers a read-only view of the current schedule removes most of the interruption and most of the risk, while the coordinators keep working exactly as they do now. Allocation logic can move later, once its rules have been written down and questioned.
Hypothetical, and the sequencing point is the transferable part: replace the part carrying business risk first, not the part that is most annoying to maintain.
Common questions
How many rows is too many? Size is rarely the real problem. Modern spreadsheets handle far more rows than most businesses have. What fails first is concurrency, rules and traceability, all of which break at a few hundred rows if several people are involved.
Can we keep the spreadsheet as a backup? Running both in parallel is tempting and it reliably produces two versions of the truth. If a transition period is needed, make one system authoritative from a specific date and make the other read-only.
Our spreadsheet has macros nobody understands. Is that a problem? It is one of the clearer cases for moving, particularly if the person who wrote them has left. Undocumented automation inside a file that several people edit is a fragile arrangement, and the failure mode is silent: wrong numbers rather than an error.
What does moving off actually involve? More than copying the data across. Existing spreadsheet data is almost always messier than anyone believes: duplicates, inconsistent naming, dates in three formats, blank cells that mean something. Deciding what to do with each category of mess is the work, and it is worth budgeting for separately rather than assuming it is included.
The short version
- Spreadsheets fail by becoming systems nobody decided to build. There is no alert, so the signals have to be looked for.
- Six signals: concurrent editing, one person as the system, multiplied copies, no record of who changed what, rules relying on memory, and use as an interface for other people.
- The last one is the strongest. When a spreadsheet has become customer-facing, replace that part first and leave the internal file alone.
- Custom software is the fourth option, not the next one. Fix the spreadsheet, try a database-style tool, or buy something built for the job first.
- Keep spreadsheets for modelling, analysis and one-off work. They are strong where the shape changes and weak where records must stay reliable.
- Migrating the data is a project of its own, and the mess in existing data is always larger than expected.
Where to take this next
If the part that has become customer-facing is the pressing problem, customer portals covers how to give people a view of their own information without rebuilding the process behind it.
If you are not yet sure whether the answer here is a tool, a bought product or a build, website, web application or custom software settles the vocabulary, and build or buy covers the decision itself.
If you want a second opinion on which signal is your real risk, describing the spreadsheet and who touches it is usually enough. Discuss your idea.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — how a working file becomes a system
Concept. A single spreadsheet outline at the left, with one person connected to it. Moving right across the frame, connections accumulate: a second editor, a copy branching off, an arrow out to a customer, an arrow to an invoice, a dotted line to a macro. The file itself does not change size or appearance, which is the point. A brass marker sits at the moment the first outward arrow to a customer appears, labelled this is where it became a system.
Purpose. Shows the article's central observation, that nothing visible changes at the moment the risk arrives.
Composition. Wide, roughly 3:1, left to right, no timeline numbers.
Alt text. A spreadsheet used by one person gradually accumulates a second editor, copies, and outward connections to customers and invoices, with the moment it became customer-facing marked as the point it became a system.
Supporting visual — four options, not one next step
Concept. Four options as steps of increasing height: fix the spreadsheet, database-style tool, buy something, build something, with cost and time indicated by height. A dotted arc arches from the first step directly to the fourth, labelled the usual jump, drawn to look like the long way round.
Purpose. Counters the article's named trap, which readers frequently walk into after recognising the signals.
Placement. At the head of "What to try before custom software".
Alt text. Four options of increasing cost, from fixing the spreadsheet to a database tool, buying a product, and building software, with a dotted arc showing businesses commonly jumping straight from the first to the last.