All articles

Operations

Spreadsheets are fine, until they become load-bearing

June 26, 20266 minute readNexwawe Infotech

Nobody should feel bad about running part of their business in a spreadsheet. It is fast, free, and everyone can already use it. The problem is not that spreadsheets are bad, it is that they never announce the moment they stop being adequate.

The signals that actually matter

Most "you need a real system" arguments are about size. Size is the least useful signal. A 40,000-row spreadsheet that one person updates on a schedule is fine. A 200-row spreadsheet that four people edit simultaneously and that feeds an invoice run is not.

  • More than one person edits it at the same time, and you have started keeping copies with names like "final v3 (Priya)".
  • Someone has to remember to do something in it, and things go wrong when they are on leave.
  • It contains a formula nobody currently employed fully understands.
  • Another process depends on it: billing, payroll, dispatch, reporting to a regulator.
  • You cannot answer "who changed this, and when?"
  • Access is all-or-nothing: everyone who can read it can also break it.

Why the third and fifth signals are the serious ones

An unowned formula and a missing audit trail are different from the others, because they are not inconveniences, they are risks you cannot see the size of. When something downstream is wrong, you have no way to find out when it started being wrong or what else was affected.

This is the point where the spreadsheet has become load-bearing: the business depends on it, but nobody can verify it.

What replacing it should not mean

The common mistake is to rebuild the whole spreadsheet as an application. Most of a spreadsheet is scratch work, and rebuilding scratch work faithfully produces expensive software that is worse than the spreadsheet was.

The better approach is to move the load-bearing part into software (the records, the rules, the permissions, the history) and leave the exploratory part where it is. People can keep exporting to a spreadsheet to think. They just should not be storing the source of truth there.

A realistic first step

Take the one process that other things depend on. Give it real records, a permission model, a change history, and a report. Leave everything else in the spreadsheet for now.

This is deliberately unambitious, and that is the point: it removes the risk without requiring the whole operation to change at once.

Talk it through

Is this the problem you are working on?

Describe your workflow and we will tell you what we would build first, and what we would leave alone.

Start a project