How to know whether a spreadsheet should become software

Spreadsheets are not the enemy

It is fashionable for software companies to treat spreadsheets as a problem to be eradicated. They are not. A spreadsheet is the fastest way yet invented to model something you do not fully understand, and most good internal software starts life as one.

The question is not whether you have a spreadsheet. It is whether this particular spreadsheet has outgrown being one.

Five signals it has

1. Two people need it at the same time

The moment a spreadsheet is shared, you inherit a category of problem it was never designed for: simultaneous edits, someone working on a downloaded copy, a sort applied to one column without the others.

Cloud spreadsheets have improved this. They have not solved it, because the underlying model is still a grid anyone can restructure.

2. A mistake in it is expensive and invisible

The classic failure is a formula whose range stops one row short of the data. Nothing errors. The total is simply wrong, and stays wrong, often for months.

If a silent error in this file would cost real money or mislead a real decision, it needs validation that a spreadsheet cannot give it: required fields, constrained values, relationships that cannot be broken by inserting a row.

3. Somebody has to remember to run it

Any process whose reliability depends on a person remembering a weekly task will fail eventually — usually during a holiday, and usually quietly.

If your spreadsheet has a ritual attached (“every Monday, paste the export in here, then refresh the pivot”), that ritual is a scheduled job waiting to be written.

4. It has become a database with a UI problem

Tell-tale signs: a lookup table on a second sheet, a column of concatenated keys, colour coding that encodes status, a tab per month, or rows nobody may delete because something else references them.

These are all database concepts, implemented by hand. At that point you are maintaining a database with none of a database’s safety.

5. Its output feeds something official

Payroll, invoices, regulatory returns, prices customers see. When a spreadsheet’s output leaves the building, the cost of an error stops being internal.

SinaTools is a clear case: hundreds of product prices that moved with exchange rates and raw-material costs, edited page by page, with a published price list that was routinely out of date. One upload now reprices the whole catalogue and regenerates the PDF.

When to leave it alone

One person uses it. If a single person owns it, operates it and depends on it, the coordination problems that justify software do not exist.

It changes shape every month. If the columns are still moving around, the thinking is not finished. Software fixes a structure in place, which is exactly wrong while you are still exploring. Let it stabilise first.

It exists to think with. Models, scenarios, what-ifs, one-off analysis. Spreadsheets are genuinely the best tool for this, and always will be.

It would be a worse experience as software. Bulk editing, ad-hoc sorting and free-form annotation are things spreadsheets do brilliantly. If those are the main uses, a form-based app will be a downgrade and people will quietly go back to the spreadsheet.

The halfway option most people miss

You do not have to replace the whole thing. Often the highest-value move is to keep the spreadsheet as an input and automate what happens around it.

That might mean a validated upload that checks the file and rejects bad rows before anything is written, or a scheduled job that does the Monday ritual on its own. Both remove the failure mode without forcing anyone to abandon a tool they are fluent in.

How to start

Pick the spreadsheet where a silent error would hurt most. Write down what it does in plain sentences — not the formulas, the purpose. If that description runs to more than a page, you have found the one that outgrew itself.

Then build the narrowest possible replacement for the riskiest part, and leave the rest alone until it earns its own replacement.