In Defence of the Spreadsheet: Why Your Client's Excel Monster Might Not Need Saving

There's a ritual every contract developer knows. You sit down with a prospective client — say, a furniture maker in Sheffield doing £2m a year — and they show you The Spreadsheet. It's called Orders_FINAL_v7_Mark.xlsx. There are seventeen tabs. One of them is called 'DO NOT TOUCH'. A formula in cell F42 references a cell three sheets over that nobody can explain.

Every fibre of your being screams rewrite this as a proper app. Resist that urge. Sit on your hands if you have to.

The spreadsheet is doing its job

Here's an uncomfortable truth: that spreadsheet has run the business for nine years. It survived the pandemic, two accountants and Mark leaving. It works. The staff know it. The owner can open it on her phone and see whether she can afford a new van this quarter.

When we replace a working spreadsheet with a custom web app, we don't just swap tooling — we swap who holds the power. Suddenly every tiny change needs a developer, a sprint, an invoice. What used to take Doris in accounts thirty seconds now requires a change request. For a five-person business, that's almost always a worse outcome, even if the code is beautiful.

A spreadsheet is a programming environment with a zero-second deploy time and a user interface the whole country already understands. That's a genuinely hard act to follow.

When the spreadsheet really is a bomb

That said, not every Excel habit is harmless. There's a spectrum, and the danger isn't complexity — it's consequence multiplied by fragility. Ask these questions:

• How many people depend on it? A rota for four warehouse staff is fine. The same rota for 300 staff across three sites, with no audit trail, is a GDPR and payroll incident in waiting.
• Does it handle money or personal data? Those raise the stakes enormously. A formula that silently rounds National Insurance contributions wrong is not a quirk, it's a liability.
• Is there one copy? If the file lives on someone's desktop and gets emailed around, you have no version control, no backup story and no idea which version is truth. One v7 versus v7 (Mark's copy) discrepancy away from chaos.
• Can a single edit break it silently? Spreadsheets fail quietly. Nobody gets an error; the number is just wrong, and by the time anyone notices, three months of orders are mispriced.

If you tick two or more of those boxes, you've found the spreadsheet that's actually worth replacing — and, crucially, the client will likely agree once the risk is spelled out in terms of pound signs rather than software architecture.

A framework for deciding if code earns its keep

Custom software has a maintenance cost that never stops accruing, like ground rent on a flat. Before pitching a rebuild, the honest maths looks like this:

Annual cost of the spreadsheet = hours spent fixing, checking and panicking about it, multiplied by the hourly cost of the people doing it, plus an estimate of what a single failure would cost (a wrong payroll run, a lost customer order, an ICO fine).

Annual cost of the software = build cost amortised over a realistic lifespan (be pessimistic — three to five years), plus hosting, plus ongoing tweaks, plus the developer dependency tax.

If the spreadsheet number isn't clearly bigger, don't build the thing. This sounds obvious, but plenty of us talk ourselves out of it because building things is more fun than telling a client their setup is fine. "It's fine" doesn't make a portfolio piece.

The middle path nobody pitches

There's also a lot of ground between "leave it alone" and "full custom platform". Move the file to SharePoint or OneDrive and you've solved versioning and backups in an afternoon. Add a bit of Power Automate to email a daily snapshot. Lock the formula cells. Put data validation on the order column so people stop typing "ASAP" into a date field.

These interventions cost hundreds, not tens of thousands, and they eliminate most of the genuine risks. Often the best engineering decision is a half-day of consulting rather than six weeks of development.

The humility dividend

There's a career benefit here too. Developers who can say "you don't need me for this" earn a different kind of trust — and when that client does eventually need something built, you're the first person they call, because you weren't trying to sell them a rebuild they didn't want.

The spreadsheet isn't the enemy. Unmanaged risk is. Learn to tell the difference, and you'll be a better engineer than most people who can refactor a monolith in their sleep.