Software
When a Spreadsheet Quietly Becomes a System
Nobody decides to run a department on a spreadsheet. It happens one column at a time, and a few specific signs tell you when a spreadsheet has become a system.
Every custom software project we’ve done started as a spreadsheet, and the spreadsheet was the right answer when somebody made it. They 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 limit and never tells you it’s out of its depth. It gets slower and more fragile, and more of the business comes to rest on it, until one file runs 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. That’s a database with no concurrency control, managed by naming convention. The moment two people need it at once, one of them is working on a copy that’s about to be overwritten.
Somebody re-keys data that already exists
An order gets typed into the spreadsheet and typed again into the accounting system. The second typing adds cost and risk and nothing else. It’s where the transposed digits come from, and it happens every day.
A report takes an evening
If month-end means somebody stays late rebuilding a pivot table, the data is in the wrong shape. You should be able to get a report by asking the data a question.
The rules live in one person’s head
There are conventions: which tab means what, what an empty cell signifies, which numbers to ignore. None of them are written down. Nobody has tested what happens when that person takes a fortnight off, and nobody wants to.
There is no history
Somebody changed a price in March. When did it change, who changed it, and what was the old price? A spreadsheet can’t tell you. For anything audited, regulated or disputed, that gap is a liability.
A system keeps a record of what changed and when.
What’s underneath the symptoms
A spreadsheet has turned into something else once it needs things a spreadsheet’s structure can’t 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 that blocks a bad value at entry, before anyone has to find it 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, and the faking is what makes it fragile.
The middle ground
We say this before we quote anything: custom software isn’t automatically the next step. There’s a real range between "one spreadsheet" and "build something," and sometimes the right answer sits in the middle.
- A better spreadsheet. Proper tables, validation, locked formula cells, and one file in shared cloud storage in place of five in email. It’s cheap, and sometimes it buys a year.
- An off-the-shelf product. If your process is standard for your trade, somebody has built it. When the fit is good, buying nearly always costs less than building.
- A low-code database tool. You get relationships, forms and permissions without a development project. The ceiling is real, and it’s a long way up.
- Custom software. For when the process is your competitive advantage, or no product fits without changing how the business works.
What it costs to wait
Sometimes waiting is correct, and you should know what it costs you while you do. Re-keying at twenty minutes a day adds up to roughly two weeks of somebody’s year. An evening a week rebuilding a report comes to six working weeks a year. Errors caught late cost far more than errors prevented.
Then there’s the risk that’s hard to price: the day the one person who understands the file is out and something urgent needs doing.
If you’re not sure which of the four options fits, the scoping quiz asks seven questions and returns a written brief describing the shape of the project. Quite often the brief says you don’t have a project yet.