Guide / Build
When to replace the spreadsheet with an app, and how.
Every business runs on a spreadsheet at some point, and most of them should. The question is not whether spreadsheets are bad. It is whether yours has quietly become the system your business depends on, with one person who understands it and no backup of anything.
- Six minutes
- 5
The signs it is time
A spreadsheet is fine right up until it is not. The switch usually shows up as a set of habits rather than a single failure.
- More than two people edit it and somebody has a private copy that is more correct
- There is a tab nobody is allowed to touch because a formula in it holds everything together
- Someone re-keys data from it into another system every week
- You have been burned by a version conflict, a deleted row, or an overwritten formula
- Customers or staff need to see part of it, so you email screenshots
- It has become slow, and the person who built it has been promoted, gone on leave, or left
What to keep in the spreadsheet
Not everything should move. Spreadsheets are the best tool ever built for one-off analysis, what-if models, and anything one person owns end to end. If the sheet is a calculator, leave it. If the sheet is a database with a login problem, that is the one to replace.
The tell is whether the value is in the formulas or in the rows. Formulas belong in a spreadsheet. Rows that other people depend on belong in a system with permissions, history, and backups.
What a replacement actually involves
The build is the shortest part. Most of the work is deciding what the spreadsheet was really doing, because a sheet that has grown for five years encodes a hundred decisions nobody wrote down. Which columns are actually used. Which statuses mean something. What happens when a value is blank.
A good replacement starts by sitting with the people who use the sheet and watching, not by reading it. Then it gets written down as a short spec, in plain language, before any code. That spec is the thing you should insist on, and the thing that should not cost you anything to walk away from.
After that, the order matters. The boring parts go in first: who can log in, who can see what, where the data lives, how it is backed up. Then the screens. Then the import of the old data, which always takes longer than anyone expects because the old data is never as clean as anyone remembers.
What it costs, in shape
A custom build through an Australian dev shop used to run somewhere between $80,000 and $250,000 and four to nine months. That is why most spreadsheets never got replaced. The mechanical part of building software has since collapsed in cost, and a system to replace a spreadsheet is now measured in weeks, not months.
What did not get cheaper is the deciding, the integrating, and the securing. Budget for those. The fixed price should cover a written scope, the infrastructure done properly, everything registered in your name, and a runbook. Then there is a monthly plan, because a system nobody is patching or backing up is a liability with your name on it, not an asset.
The mistakes that turn it into a bad build
The failures are predictable. They are the same ones every time.
- Rebuilding the spreadsheet as a spreadsheet, screen for screen, instead of asking what the business needed the sheet for
- Version one that does everything. Version one should replace the part of the sheet that hurts, and nothing else
- A developer who owns the hosting, the domain, and the code, so that leaving them means starting again
- No plan for after launch. Every system needs patching, and the one that replaced the spreadsheet holds your customer data now
Where this goes next.
Read next
How a Build works
Fixed price, a written scope before any code, everything in your name, and a monthly plan after launch.