Operations · Web applications

How to tell when your business has outgrown spreadsheets

Let us be clear at the start: spreadsheets are one of the best tools ever made for business, and this is not an argument against them. The problem is not spreadsheets. The problem is the moment one quietly stops being a spreadsheet and becomes your database, without anyone deciding that it should.

What that moment looks like

A spreadsheet becomes critical infrastructure when the business can no longer operate without it, but nothing about it is built to carry that weight. There is no access control worth the name, no audit trail, no validation, and no backup beyond somebody’s laptop.

Nobody chooses this. It happens because each individual step made sense. You added a column. Then a second sheet that looks up from the first. Then a colleague started using it. Then it became the only place the real numbers live.

Seven signs you have crossed the line

1. The filename contains a version number. If the current truth is records_final_v3_USE_THIS.xlsx, you no longer have a system of record. You have several competing ones.
2. Two people disagree about a number that should be objective. When a figure like total outstanding or active customers has more than one defensible answer, the problem is not the arithmetic. It is that there is no single place the answer comes from.
3. One person understands the formulas. This is the risk that keeps business owners awake. That person taking leave, getting a better offer, or simply being unreachable is an operational incident waiting to happen.
4. Errors surface after decisions are made. A broken reference or an overwritten row is discovered when the report has already gone to a client or a lender.
5. Data is re-typed between files. Every copy and paste is an opportunity to introduce an error that nobody will notice for months.
6. Sharing the file is the access control. If sending someone the spreadsheet gives them every column, including salaries or margins they should not see, you have no permissions model.
7. You cannot answer a simple question quickly. If “how many orders did we fulfil in Kano last quarter?” is a twenty minute job involving filters and a pivot table, the data has outgrown the tool.

The real cost is not the licence fee

Spreadsheets are cheap to buy, which is why the true cost stays invisible. The expense is in hours spent reconciling rather than working, errors that reach customers, decisions made on stale figures, and the key-person risk described above.

Put a number on the hours alone and it usually dwarfs what a proper system would cost to build. The difficulty is that the spreadsheet cost arrives in small instalments and never appears as a line item, so it never gets compared against anything.

What to build, and specifically what not to

The most common and most expensive mistake at this point is deciding to build everything at once. A business that runs on fifteen spreadsheets does not need a fifteen-module platform. It needs the worst bottleneck removed first.

Here is the sequence that works:

1. Map the process as it actually runs, not as the manual says it runs. Include the workarounds. The workarounds are usually where the real requirement is hiding.
2. Find the single worst bottleneck. Usually it is whichever step causes the most re-typing, or the one that breaks first when volume grows.
3. Put one database behind that step. One place the truth lives, with validation on the way in.
4. Then add the next step, once the first is genuinely in use and people trust it.

This is slower on paper and much faster in practice, because it produces something usable in weeks rather than a large system nobody adopts.

What good looks like

A system that replaces a critical spreadsheet needs a small number of properties, and none of them are exotic:

• One source of truth. A figure has one definition and one place it comes from.
• Validation at entry. The system refuses bad data rather than storing it and letting you find out later.
• Roles and permissions. People see what their job needs and nothing else, enforced on the server.
• An audit trail. Who changed what, and when.
• Reports that run themselves. The question you used to spend twenty minutes on becomes a saved view.
• Backups you have tested. An untested backup is a hope, not a plan.

The hard part is your data, not the software

Building the interface is the straightforward part. Moving five years of records out of spreadsheets is where the time goes, because those files contain duplicate customers under slightly different names, dates stored as text, blank rows where someone gave up, and columns that meant something different in 2022.

Expect this and budget for it. Anyone who quotes a migration without looking at the actual files is guessing, and the guess will be low.

When to stay on spreadsheets

Genuinely, sometimes the answer is to stay. If the process is small, short-lived, or used by one person who understands it, a spreadsheet is the correct tool and building software would be waste. If the volume is low enough that manual checking catches every error, you do not have a problem yet.

The signals above are the ones that matter. When a file acquires version numbers, depends on one person’s knowledge, and is the only place the truth lives, you have outgrown it whether or not it feels that way yet.