The point where a spreadsheet stops being enough

Nearly every internal system I have been asked to build started as a spreadsheet, and the spreadsheet was the right decision at the time. It was free, it worked the same afternoon, and it did not require anyone’s approval.

Spreadsheets stop working in a predictable way, though, and the useful skill is recognising the point rather than tolerating it for another year. What follows are the four signals I look for. Three of them have nothing to do with how much data you have.

If you recognise two or more, the conversation about custom software development is worth having — not because building is obviously right, but because the workaround has started costing more than it looks like it does.

Signal one: someone re-keys data between systems

The most reliable signal, and the easiest to price. Somebody exports from one place and types it into another, on a schedule.

Price it honestly: the hours per month, the salary of the person doing it, and the error rate. The last one is the part people leave out, and it is usually the larger number. Manual transcription has a non-zero error rate no matter who does it, and the cost of an error is rarely the cost of the keystroke.

Signal two: the file has a guardian

There is one person who knows why column M is that colour, and things break when they are on holiday.

This is a knowledge problem wearing a data costume. The rules of the business have been encoded in formatting, formulas, and habit, and they exist in exactly one head. That is a continuity risk, and it does not improve on its own — it compounds, because the guardian keeps adding rules only they understand.

Signal three: two versions disagree and nobody can say which is right

The moment the answer to “which is the current file” requires a conversation, the spreadsheet has stopped being a record and become a rumour.

Software solves this not by being cleverer but by making a single authoritative copy structurally unavoidable. That is genuinely the whole benefit, and it is enough on its own in a surprising number of cases.

Signal four: you cannot answer a question about last quarter

Spreadsheets record state, not history. When someone asks what a value was in March, and the file has been overwritten since, the honest answer is that the information is gone.

If your business needs to explain past decisions — to a regulator, an auditor, an investor, or a customer — this is the signal that matters most, because it is the only one you cannot fix retroactively. History you did not record does not come back. That is covered in more depth in enterprise software, where audit trails are a requirement rather than a nicety.

What I would build first, and it is smaller than you expect

Not a system that replaces the spreadsheet. A system that owns the one part causing the most pain, with an import and an export so the spreadsheet keeps working alongside it.

Replacing a working spreadsheet wholesale means reproducing years of accumulated edge cases, most of which are undocumented, and the failure mode is a six-month project that delivers something worse than the file it replaced. Taking one piece means you find out early whether the model is right, while the fallback still exists.

The counter-argument is real: two systems for a while is genuinely more confusing than one, and if the team is small enough that everyone touches everything, that confusion can cost more than the migration would have. I would rather name that than pretend the incremental path is free.

What this does not justify

None of the four signals justifies a platform. They justify replacing one process. The failure I see most often is a project that starts as “the ordering sheet is a mess” and arrives at “an integrated operations system,” at which point the budget belongs to a different conversation and the ordering sheet is still a mess eight months later.

Build the narrow thing. If it works, the next narrow thing is easier to justify and cheaper to build because the first one established the model. If it does not work, you have spent a fraction of the platform budget to learn that the model was wrong, which is the cheapest way that lesson is ever available.

Related reading: custom software covers the build-versus-buy test in general, and application development covers the decisions that set the cost once you have decided to build.

The limit on this

These signals tell you the spreadsheet has become expensive. They do not tell you that custom software is the cheapest replacement — an off-the-shelf product often is, particularly for ordering, scheduling, and CRM, where the market is mature and your process is probably less unusual than it feels. Check that first. It is a shorter conversation and sometimes it ends the matter.