Spreadsheets and Access
The spreadsheet is not the problem. Being the only copy is.
Somebody in your business built something clever in Excel, or in Access fifteen years ago, and it works. It has run the business for years and it is genuinely good.
Then it becomes a risk. One person understands it. Two people cannot use it at once. There is no history of who changed what. And the file lives on a laptop that has never been backed up in a way anyone has tested.
Respect the spreadsheet
It survived because it fits. That is the brief, not the enemy.
Most software projects that replace a spreadsheet fail for the same reason: the new system implements what somebody thought the spreadsheet did, rather than what it actually does. The formulas carry a decade of exceptions, and the exceptions are the business.
So the first job is reading it properly. Every formula, every lookup, every column somebody added in 2019 and never explained. That reading is the specification, and it is the part that decides whether the rest is worth anything.
Access databases are the same story with a deadline
An Access database usually runs on one machine, sometimes an old one, occasionally an operating system nobody supports any more. It works until the machine dies, at which point it becomes an emergency instead of a project.
What actually changes
Everything it did, plus the four things it could not.
Several people using it at once, without a file lock or a copy called “final v3 REAL”. A record of who changed what and when. Validation, so the date column cannot contain the word “approx”. Access from a phone. And backups that happen whether or not anybody remembers.
None of those are exciting. All of them are the reason the spreadsheet has quietly become a risk rather than an asset.
The scope
What gets built, and what we leave alone.
What gets built
- Every rule the spreadsheet actually implements, read out of the formulas rather than guessed
- Multi-user access with no file locking and no rival copies
- A change history, so you can see who edited what and when
- Validation that stops the data going bad at entry rather than finding it later
- The reports the spreadsheet produced, plus the ones it could not
- Phone access for whoever needs it in the field
- Automatic backups that are actually tested
- A migration that brings the history across, not just the current state
What we will not do
- Replace a spreadsheet that is genuinely fine. Plenty are, and we will say so
- Rebuild it without understanding it. If the logic cannot be read, the project starts with reading, not building
- Take on a model that is really an accounting system in disguise. That belongs in accounting software
The honest test. A spreadsheet needs replacing when more than one person needs it at once, when a mistake in it would be expensive, or when only one person understands it. If none of those are true, keep it and spend the money elsewhere.
The other sum
Not a subscription. The hours, and the risk.
Do it on your own number
This one is rarely about licences. Put in the hours a week the spreadsheet costs across everyone who touches it, at a fair hourly rate, and then think about what a lost file would cost.
Common questions
Answered plainly.
How much does it cost to replace a spreadsheet with an app?
From $5,000, typically three to eight weeks. The variable is not the screens, it is how much logic the spreadsheet holds. A pricing model with a decade of exceptions takes longer to read than to build.
We have an old Access database. Can you replace it?
Yes, and this is one of the most common projects we take. The usual pattern is an Access database on one ageing machine, understood by one person. We read the logic, rebuild it properly, and bring the history across.
Will we lose the logic in the spreadsheet?
Not if it is read properly first, which is why the first stage of these projects is going through the formulas rather than starting from a wish list. The exceptions buried in the formulas are usually the business rules nobody has written down anywhere else.
Should we use Airtable or a no-code tool instead?
Sometimes, and we will say so. No-code is a good answer for a small tool used by a few people. It stops being the answer at per-seat pricing across a whole team, or when the logic is complex enough to fight the builder.
Can several people use it at once?
Yes, and it is usually the first thing people notice. No file locks, no copy named final v3, and a record of who changed what.
Where to next
Bring the spreadsheet.
The real one, with the tabs nobody else understands. Twenty minutes with it open tells us whether it needs replacing, and roughly what that would take. If it is fine as it is, we will tell you that.