Nobody decides to let a spreadsheet start running the business. It started as a list. Then somebody added a column, and a tab, and a formula that referenced the tab. Then someone built a lookup so the invoice numbers filled themselves in. Now four people have it open, one of them is the only person who understands the pricing sheet, and nobody opens it on a Friday afternoon in case something breaks before the weekend.
First, the spreadsheet deserves credit. It got you here. It let you invent your process while you were still working out what the process was, without a budget or a project or anyone's permission. No software would have let you move that fast, and the fact that it now creaks is not a design failure, it is what success looks like from the inside. Most companies never reach the point where their spreadsheet is under strain.
The useful question is not whether spreadsheets are bad. It is whether yours has crossed from being a tool into being a system, because those fail in different ways.
Seven signs the spreadsheet is running your business
- More than one person needs it at once, and you have rules about it. A message asking whether anyone is in the file. A convention about who edits which tab. The moment coordination becomes a human protocol, you have outgrown it.
- Nobody can tell you who changed something, or when. Version history exists but nobody uses it forensically. A number is wrong, and the honest answer to how it got that way is that nobody knows.
- One person is the only one who really understands it. The pricing tab, the macro, the reason column K is hidden. If they were away for a fortnight, would the business slow down? That is not a spreadsheet, that is a single point of failure with a person attached.
- People copy it before doing anything risky. Duplicates named final, final-2, and a date. Everyone does this because they do not trust that a mistake can be undone, and they are right not to.
- Data gets typed in twice. Out of the spreadsheet into an invoice, into an email, into another system. Every retype is a chance to be wrong, and the errors are found by customers.
- It is slow, or it has started breaking. Recalculation takes noticeable seconds. Formulas break when someone sorts. Reports come from a pivot table that only one person can rebuild.
- You cannot answer an obvious question. How many of these did we do last quarter, for this kind of customer, and what was the average. If getting that means an afternoon of exports, you no longer have a system of record, you have a pile of records.
Three or four of those and it is worth a conversation. Five or more, particularly if one of them is the single-person one, and the risk has probably already outgrown the cost of doing something about it.
What usually replaces it, and it is not exotic
People imagine an enormous system with a year-long implementation. In practice what replaces a working spreadsheet is a plain web app: a handful of screens, a proper database underneath, and a login. Nothing clever.
- A form to put things in, which validates as it goes so bad data cannot get in rather than being cleaned up later.
- A list to look at, filterable and searchable, which is the tab everyone lives in.
- A detail view for one record, with its history attached, so who changed what and when is a fact rather than a guess.
- Two or three reports that answer the questions you actually ask, rather than a reporting engine nobody learns.
- Permissions, so the people who should not be editing prices cannot edit prices.
- An export button, because you will still want a spreadsheet sometimes, and that is fine.
That is genuinely it for a first version. The temptation is to specify everything the spreadsheet has ever done, which is how a small project becomes a large one. Build the part that ten people touch every day and leave the quarterly oddity in a spreadsheet where it is doing no harm.
What you keep and what you lose
| You gain | You give up |
|---|---|
| Several people working at once, without a protocol. | The ability to restructure it yourself in five minutes. |
| A history of who changed what and when. | Ad-hoc formulas invented on the spot for a one-off question. |
| Validation, so bad data cannot get in. | The freedom to put anything in any cell, which is sometimes genuinely useful. |
| Permissions, so sensitive columns are actually protected. | Zero cost. There is now a bill, and a supplier. |
| Reports that are always current, not rebuilt by hand. | Instant change. Some things now need a developer. |
| Something a new person can learn in an hour. | The comfort of a tool everyone already knows. |
The second column is the reason to keep the spreadsheet for what it is good at rather than banning it. Exploration, one-off analysis and quick modelling belong in a spreadsheet forever.
Moving the data without losing it
This is the step that gets underestimated, and it is usually the largest single piece of work. Years of a spreadsheet contain inconsistencies that a human eye glides over and a database refuses.
- Look at the actual data first, before designing anything. The same customer spelled three ways, dates in two formats, a status column with eleven values where you believed there were four. This tells you what the system has to tolerate.
- Decide what is worth bringing. Often the answer is the last two years live, and everything older kept as a read-only archive. Migrating a decade of history is expensive and rarely used.
- Clean it before, not during. A migration that also tidies is two projects fighting each other.
- Run both for a fortnight. Enter into the new system, keep the spreadsheet updated in parallel, compare. Tedious, and it is what turns a nervous switchover into an uneventful one.
- Keep the old file forever, read-only. It costs nothing and one day someone will ask what happened in a month three years ago.
Start smaller than you think
The most common way this goes wrong is not choosing badly. It is trying to replace the whole spreadsheet at once, because the spreadsheet has quietly accumulated fifteen jobs and specifying all of them turns a two-month project into a nine-month one.
A better approach is to find the one thing that hurts most, usually the tab that several people fight over, and move only that. Everything else stays in the spreadsheet, which continues to work exactly as it does today. You get the audit trail and the concurrent access where you actually needed them, in weeks rather than months, for a fraction of the cost, and you learn what the real requirements are by using something rather than by imagining it.
Then move the next thing, if it still seems worth it. Often it does not, which is useful information you could only have bought this way. The spreadsheet shrinks over a year instead of being replaced in one nervous weekend, and at no point is there a day where everything is new and nobody is sure how anything works.
Roughly what it costs and how long
| Scope | Typical range | Timeline |
|---|---|---|
| One process, a few screens, a handful of users | $12,000 to $30,000 | Four to eight weeks |
| Several linked processes, roles and permissions, reporting | $30,000 to $80,000 | Two to four months |
| The above plus connecting to accounting or other systems | $50,000 to $150,000 | Three to six months |
Illustrative from the kind of work we quote, not a price list. Budget for ongoing maintenance too, roughly 15 to 25 per cent of the build a year. And check before commissioning anything that a product does not already exist for your industry, because sometimes one does.
That last point deserves emphasis rather than a footnote. Before building anything, search properly for a product aimed at your trade. If one fits, buy it. Custom software vs off-the-shelf has a scoring framework for exactly this decision, and it recommends buying more often than building.
Not for you if
One thing we would say to anyone slightly embarrassed about the state of their file: we have never once seen a spreadsheet running a business and thought less of the people running it. It usually means someone worked out a good process before anyone gave them a budget, which is a better sign than a tidy system nobody uses.