This article is part of our Journal archive. Any prior offers reflect its publication date. Read our current services and approach.
Every growing business has one file holding up an operation it was never designed to hold up. Here is how to tell when it has become a liability, and how to replace it without buying a disaster.
Somewhere in your business there is a spreadsheet doing a job nobody planned for it to do.
It started as a quick way to track something for a couple of weeks. Then a column got added. Then a tab. Then someone built a formula that referenced another file, and someone else added conditional formatting that means something specific to exactly one person. Now it schedules your crews, or prices your jobs, or tracks what you owe suppliers, and if the laptop it lives on died tonight you would have a genuinely bad month.
This is not a failure of discipline. It is what competence looks like under time pressure. Someone needed the problem solved on a Tuesday and solved it. The spreadsheet is a monument to the fact that your business grew faster than its systems, which is a good problem in the way that a leaking roof over a full house is a good problem.
The question is not whether the spreadsheet is embarrassing. It is whether it has crossed from useful to dangerous.
Spreadsheets are good, and most of yours should stay
Before the case against, the case for. Spreadsheets are the most successful software ever built for ordinary people. They are instantly editable, they require no training, they cost almost nothing, and the person who understands the problem can fix the tool themselves at the moment they notice it is wrong. Custom software takes that last property away, and it never fully gives it back.
So the default answer is leave it alone. A pricing calculator one person uses, a checklist, a budget model, a list of leads you look at twice a week: none of that needs to become an application, and turning it into one usually makes it worse. Slower to change, more expensive, and now it needs a developer to breathe.
Replace a spreadsheet when it has stopped being a document and started being a system that other things depend on.
The four signs it has become a liability
Two people cannot use it at once without a phone call. The moment coordination is required to avoid overwriting each other, the file is not a tool, it is a shared resource with no locking. Cloud editing helps and hides the deeper issue, which is that two people editing the same cells have no way to know whose intent should win.
The rules live in one person's head. Ask what the yellow highlight means, or why row 40 is excluded from the total. If the answer is a person's name rather than a written rule, you do not have a system. You have an arrangement with an employee, and it ends when they take a holiday, get promoted, or leave.
You cannot answer a simple question about the past. How many jobs did we run last March, and what did they average. If answering means rebuilding a file from three older copies with names like final-v2-USE-THIS, you are not keeping records. You are keeping the current state and quietly discarding history.
A mistake is silent. Someone types over a formula and nothing tells anyone. There is no trail of who changed what, and the error surfaces weeks later as a number nobody can explain. Silent failure is the one that actually costs money, because by the time you notice, you have made decisions on top of it.
One of these is survivable. Three or four means the spreadsheet is now load-bearing, and it is holding up more weight than it was ever built for.
What replacing it actually looks like
Here is where most businesses go wrong. They conclude they need a platform, go shopping for enterprise software, and buy a large product with a long implementation, an annual contract, and modules for eleven things they do not do.
The predictable ending is that people use about a fifth of it and quietly export to a spreadsheet to get their actual work done. Now you are paying for the platform and still running on the file, except the file is worse because it has to reconcile with the platform.
The alternative is smaller and much less impressive to describe. A real database instead of cells, so the same fact is stored once. A screen shaped like the job the person is actually doing, rather than a generic grid. Permissions, so the people who should not be able to change a price cannot. A history of who changed what and when. Validation that refuses impossible entries at the moment they are typed instead of leaving them to be discovered later. And an export, so the data can always leave.
That is the whole ambition. It is not a transformation. It is taking the one workflow that has outgrown the file and giving it a floor to stand on, while everything else stays exactly as it is.
The migration is the hard part, and it is always the data
The build is rarely what sinks these projects. The data is.
Your spreadsheet has three formats of phone number, a customer whose name is spelled two ways, dates that are text in the older rows, a column that meant one thing until 2024 and something else after, and forty entries where someone used the notes field to record an exception the system knows nothing about.
None of that is written down anywhere. It lives in the head of whoever maintains the file, and they will not think to mention it, because to them it is not a rule. It is just how it is.
This matters when you are buying, because it is the part that quietly doubles the timeline. Any developer or vendor who has not asked to see your real data has not costed the actual job. They have costed the clean version of it that exists in their imagination.
How to de-risk the whole thing
Ask for it to be built against your real, messy data before you pay for it.
Not sample data. Not a demo populated with tidy fictional customers. Your actual export, with the duplicates and the two date formats and the notes column full of exceptions. That single condition tells you almost everything you need to know, on both sides. You find out whether the person understood your process or just nodded through the meeting. They find out what they are really quoting. The awkward parts surface in week one, when they are cheap, rather than in month three, when they are expensive and everyone is already committed.
This is why we work the way we do. Before a client pays anything, we build a working version of the thing itself, running on their own material, on a real URL they can open and use. Whether that is a website, a mobile app, an internal system, or a piece of enterprise software, the terms are the same: no obligation, no money down. Use it, show it to the person who actually maintains the spreadsheet, and decide from there. If it is wrong, you owe us nothing. If it is right, it is already the foundation of the real build.
The spreadsheet does not deserve contempt. It kept the business running while the business was busy growing. It has just reached the end of what one file can honestly hold, and the honest move is to find that out with something you can use, before you spend a dollar on something you cannot.