Every growing business has one. A spreadsheet that started as a quick fix for something — a rota, an order tracker, a job queue — and quietly became load-bearing infrastructure.
Nobody planned for this. It just happened.
The signs you've hit the wall
You know the spreadsheet is in trouble when more than one person needs to edit it at the same time. Or when someone accidentally deletes a formula and you don't find out for three days. Or when a new member of staff takes two weeks to understand it, and even then they're not quite sure.
The data is probably fine. The problem is everything built around it: the copying, the emailing, the manual steps that exist because the spreadsheet can't do them itself.
Why businesses don't fix it sooner
The honest answer is that it still works. Slowly, anxiously, with the occasional late-night repair job — but it works. And building something proper feels like a big project that requires a budget conversation nobody wants to have.
The other reason: it's genuinely hard to scope. "We need something better than this spreadsheet" isn't a brief. It's a direction.
What a scoping session actually looks like
A good scoping session starts not with the tool but with the process. What triggers it? Who touches it? What decisions does it feed? Where do things go wrong?
From that conversation you get something useful: a list of the five or six things that need to be true for the problem to be solved. That list becomes the spec. The spec becomes a fixed-price quote.
Most of the projects we do at Fuselab start this way. A £750 discovery session, a few weeks of build, and the spreadsheet retires.
The question worth asking now
If that spreadsheet disappeared tomorrow, what would break first? That's the thing to fix.
Everything else can wait.