When a Spreadsheet Quietly Becomes a System

Every custom software project we have ever done started as a spreadsheet, and the spreadsheet was the right answer when it was made. Somebody needed to track twelve things, opened Excel, and solved the problem in an afternoon. That was good judgement.

The trouble is that a spreadsheet has no upper bound. It never tells you it is out of its depth. It just gets slower, more fragile, and more load-bearing until one file is running a department and one person understands it.

The signs it has crossed over

The filename has a date or a version in it

Inventory_2026_v4_FINAL_use_this_one.xlsx. This is a database with no concurrency control, being managed by naming convention. The moment two people need it at once, one of them is working on a copy that is about to be overwritten.

Somebody re-keys data that already exists

An order is typed into the spreadsheet and typed again into the accounting system. That second typing is pure cost and pure risk — it is where the transposed digit comes from, and it happens every single day.

A report takes an evening

If month-end means somebody stays late rebuilding a pivot table, the data is in the wrong shape. A report should be a question you ask, not an artefact you assemble.

The rules live in one person’s head

There are conventions — which tab means what, what an empty cell signifies, which numbers to ignore. They are not written down. Nobody has tested what happens when that person is on holiday for a fortnight, and nobody wants to.

There is no history

Somebody changed a price in March. When, who, and what was it before? A spreadsheet cannot answer this. For anything audited, regulated, or disputed, that is not an inconvenience — it is a liability.

A spreadsheet stores what is true now. A system stores what was true, and when it changed.

What you are actually feeling

Underneath the symptoms, a spreadsheet stops being a spreadsheet when it needs things a spreadsheet structurally cannot provide.

• Multiple people at once without overwriting each other
• Relationships between records — this order belongs to this customer, contains these items, ships on this date
• Validation so a bad value cannot be entered rather than being found later
• Permissions so the right people see the right things
• An audit trail of who changed what
• Access from a phone in a truck or on a job site

You can fake several of these in a spreadsheet. The faking is what makes it fragile.

The honest middle ground

Custom software is not the automatic next step, and we say so before quoting. Between "one spreadsheet" and "build something" there is a real range, and sometimes the right answer is in the middle.

1. A better spreadsheet. Proper tables, validation, locked formula cells, one file in shared cloud storage instead of five in email. Cheap, and it buys a year sometimes.
2. An off-the-shelf product. If your process is genuinely standard for your trade, somebody has built it. Buying is nearly always cheaper than building when the fit is good.
3. A low-code database tool. Relationships, forms, and permissions without a development project. Ceiling is real but it is a long way up.
4. Custom software. When the process is the competitive advantage, or no product fits without changing how the business works.

What it costs to wait

Waiting is sometimes correct, and it is worth being honest about the meter that is running while you do. Re-keying at twenty minutes a day is roughly two weeks of somebody’s year. An evening a week rebuilding a report is six working weeks a year. Errors caught late cost far more than errors prevented.

And the risk that is hard to price: the day the one person who understands the file is unavailable and something urgent needs doing.

If you are not sure which of the four options you are in, the scoping quiz asks seven questions and returns a written brief describing the shape of the project — including, quite often, the finding that you do not have one yet.