In this article (9 sections)
Almost no company starts with a system. It starts with a spreadsheet, and the spreadsheet works. That's the part this discussion usually skips: Excel isn't a mistake to be corrected, it's a tool that solved the problem for years, and that's why it's still there.
The problem shows up later, and it doesn't show up all at once. It shows up as an accumulation of small frictions, none of which justifies anything on its own.
The signals that actually matter
There's a difference between "the spreadsheet is annoying" and "the spreadsheet is done". These are the second kind.
Somebody spends hours consolidating. If one person spends Monday morning pulling together the sales sheet, the inventory sheet and the bank sheet to produce one number, that isn't admin: it's a system built by hand. You're already paying the cost, just in salary instead of software.
There's more than one version of the truth. `inventory_final_v3_OK.xlsx`, the copy on the sales rep's laptop, the one in the shared drive. When two people answer the same question differently, the data has stopped being trustworthy, and untrustworthy data doesn't get used to decide anything.
The process depends on somebody remembering. Telling the warehouse, sending the packing slip, recording the payment. None of that is written down anywhere: it's in one person's head. That's the most expensive risk and the most invisible one, because it doesn't show until that person takes a vacation.
You can't give partial access. You want a sales rep to see their customers but not the cost list. In a spreadsheet that doesn't exist: either they have the file or they don't.
The typo reaches the customer. A miscopied cell that ends up on an invoice, a packing slip with the wrong quantity. In a spreadsheet there's nothing validating anything.
No single one of these signals justifies a build. Three or more together do: each one is costing money every month and none of them is going to fix itself.
The signals that do NOT justify the jump
This is worth saying too, because there are reasons that sound good and aren't enough.
- "It looks unprofessional." If the customer never sees the spreadsheet, that isn't a reason. It's internal aesthetics.
- "Everyone else has a system." Somebody else's system is solving somebody else's problem.
- "Our accountant recommended it." They may be right, but ask what for. If it's only for the bookkeeping side, what you may need is an integration, not a system.
- "It's slow." Before you build, check whether the problem is the spreadsheet or the process. A bad process, digitized, is still a bad process — it just costs USD 12,000 now.
That last point is the most important of all. A system doesn't organize a disorganized operation. It freezes it. If nobody today knows what the approval path for a discount is, the software isn't going to invent one: it's going to force you to define it, and that definition is your work, not the vendor's.
What you gain and what you lose
You gain the obvious: one version of the data, permissions by role, validations that stop entry errors, a history of who did what, and the ability for two people to work at the same time without stepping on each other.
You lose something almost nobody mentions in the sales meeting: immediate flexibility. In Excel, when you need a new column, you add it yourself in thirty seconds. In a system, that column is a request, an estimate and a deploy.
That trade is real and it's worth understanding before you sign. The spreadsheet is infinitely malleable and that's why it's a disaster at scale. The system is rigid and that's why it's reliable. You're trading one for the other on purpose.
The practical consequence: keep out of the system whatever is still changing. An exploratory analysis, a calculation that changes every quarter, a dashboard you're still testing. That stays in the spreadsheet, and it should.
The three paths, without romance
Clean up the spreadsheet
It sounds like doing nothing, but it's the right answer more often than you'd think. A spreadsheet in Google Sheets, with data validation, per-sheet permissions and a couple of automations, covers a good share of the cases a small business has.
When it's enough: fewer than five people entering data, one main process, no need to give outside access.
Cost: your own hours.
Ceiling: low, and you hit it fast the moment a second person starts entering data at the same time.
An off-the-shelf product
An ERP or an industry-specific system that already exists. You install it, configure it, start next month.
When it's enough: your operation looks like everyone else's in your industry. You invoice, you track inventory, you follow receivables, and none of it has an odd twist.
Cost: a monthly per-user subscription, plus implementation.
Ceiling: customization. Anything the product doesn't cover, you either handle outside it or you change your process.
A custom build
When it's the right call: when what sets you apart is exactly the process no off-the-shelf product covers. A pricing logic of your own, a particular approval path, an integration a large customer demands in a specific shape.
Cost: USD 3,000 to 8,000 for something narrow, USD 8,000 to 25,000 for a full business system for a small company.
Ceiling: high, but it's yours to maintain.
The question that settles the decision isn't which one is better. It's: is what you do differently in the process, or only in how you do it? If your differentiator is service, brand or price, and the administrative process is standard, go off the shelf. If your differentiator lives inside the process, off the shelf will flatten it.
How to make the jump without stopping the business
The most common mistake isn't picking the wrong tool. It's trying to migrate everything at once.
Start with one process, not with the company. Pick the one that hurts most —the one eating Monday morning— and do only that. A system that solves one thing well gets used. One that solves six things badly doesn't.
Let them coexist for a while. For a month or two the system and the spreadsheet will run in parallel. It's double work and it's uncomfortable, and it's the only way to find the cases nobody told you about without putting the operation at risk.
Data migration is its own project. Historical data from a spreadsheet is dirty: names written three different ways, dates stored as text, duplicated rows. Cleaning that takes time and isn't optional, because a new system with bad data is born distrusted.
One decision worth making early: how much history you migrate. Current balances and the last year are almost always enough. Bringing over eight years of transactions multiplies the cost of the migration, and almost nobody looks at them afterwards.
Define the workflow before the software defines it. Sit down with whoever does the work and write out the steps, exceptions included. That hour of conversation is worth more to the result than any technical decision that comes after.
In short
You don't replace the spreadsheet because it's bad. You replace it when the cost of keeping it —hours of consolidation, errors that reach the customer, decisions made on data nobody stands behind— is higher than the cost of replacing it.
If you can't yet put that cost in hours and dollars, it's probably early. And if you can put a number on it and the number is high, you already know what comes next.