When one spreadsheet runs your business
If you find yourself opening the same spreadsheet every morning — the one with the colour-coded tabs, the macros nobody remembers writing, the formulas only one person dares touch — you don't have a spreadsheet anymore. You have an application. It just doesn't know it.
Key takeaways
- The warning signs: it lags, only one person can safely edit it, and the formulas have turned fragile.
- You don't always need to replace it — first make it safe.
- When you do graduate it, move only the parts that have outgrown the sheet.
How a spreadsheet becomes infrastructure
It never starts as critical. It starts as a quick fix — a way to track one thing. Then someone adds a tab, then a lookup, then a macro. People start building their own work around it. A year later a real process runs through a file with no version history, no access control, and one person who understands it. Nobody decided that should happen; it just accreted.
The warning signs
You can usually feel it before you can prove it. The file has grown so large it lags every time it opens or recalculates. Only one person — usually whoever built it — can safely edit it; everyone else is afraid of touching the wrong cell. And because so many hands have been in it over the years, the formulas have quietly become fragile: a dragged cell or an inserted row breaks something three tabs away, and nobody notices until a number comes out wrong.
De-risk before you replace
Replacing it is often the wrong first move. Before that: back it up and version it so a bad save isn't fatal; protect the formula cells so a stray edit can't break them; add validation so bad input is caught at entry; write down what each part does so it isn't trapped in one head; and get a second person across it so it isn't one-deep. If it's grown so heavy it lags, splitting it or trimming dead history usually buys the speed back. That alone removes most of the risk — and buys time to decide whether you even need to replace it.
When to graduate it to a system
The signal to move isn't “the spreadsheet is big” on its own. It's when the real need is something a spreadsheet can't do safely no matter how well it's built: several people editing at once, reporting you can trust, talking to your other systems, or simply more data than the file can carry without crawling. Then move the logic to something with a proper database behind it — but only the parts that have outgrown the sheet. The rest can stay.
Frequently asked questions
Is it bad to run on spreadsheets?
No. Spreadsheets are excellent until they quietly become load-bearing and undocumented. The problem isn't the tool, it's the lack of backup, ownership and validation around it — and a file so large it lags.
How do I know when to replace it?
When the real need is concurrent editing, reporting you can trust, or sharing data with other systems — things a spreadsheet can't do safely no matter how well it's built.
Do we have to rebuild everything?
Usually not. Move only the parts that have outgrown the sheet; the rest can stay as it is.
Got a spreadsheet you can't afford to lose?
We'll help you make it safe first — and graduate only what's outgrown it.