Nobody decides to outgrow a spreadsheet. You notice it one morning.
Usually it sounds like this: two people have two versions of the same file, both are being used to make decisions, and nobody is certain which one is right. Or a customer asks a simple question — what did we quote them last time? — and three people have to be called before anyone can answer.
The spreadsheet isn't the villain here. It got the business to this point, and it did that because it's fast, free and infinitely flexible. But the same flexibility that made it useful at five people is what makes it dangerous at fifty. This article is about how to tell which side of that line you're on, and what to do about it — including the cases where the answer is to do nothing yet.
Six signs you've crossed the line
- Two people hold two versions of the truth. Someone emails a file, someone else edits their copy, and now there are two. Neither is wrong enough to notice immediately, which is precisely the problem. By the time the difference surfaces, decisions have been made on both.
- One person has become a dependency. They know which tab matters, which formula is fragile, and which numbers to ignore. Their annual leave slows the business down. Their resignation would stop it. This isn't a criticism of them — it's a structural risk the business created without meaning to.
- The same data gets entered more than once. Written in the order book, typed into the stock sheet, entered again in the accounting package. Every duplicate entry is a future disagreement with a delay on it.
- Reports arrive too late to act on. The monthly numbers take a week to assemble, so by the time you're reading them, they describe a month you can no longer influence. Management by rear-view mirror.
- Nobody fully trusts the stock number. So somebody walks the storeroom and counts. That count is accurate until the first sale of the afternoon, and everyone knows it.
- Growth makes it worse rather than better. A second branch doesn't double the work — it quadruples the reconciliation. New staff take weeks to become useful because "how we do it here" isn't written anywhere except in people's heads.
If three or more of these are true this week, the spreadsheet has stopped being a tool and started being a tax.
What an ERP actually is, without the jargon
Software vendors have made this word do too much work, so here's the plain version.
Accounting software records what happened. An ERP runs what's happening. One sale, entered once — and the stock reduces, the invoice raises, the customer's balance updates and the report already knows. There's no second entry, because there's only one record.
That's the whole idea. Everything else — modules, dashboards, workflows — is detail hanging off that single principle: the business keeps one set of numbers, and everyone reads from it.
The part most articles skip: when you shouldn't
Most agency writing about ERP is trying to sell you one. So let's be straight about when the answer is no.
If an off-the-shelf product fits your process as it is, buy it. Configuring an existing system is faster and cheaper than building one, and there are good ones. The question isn't whether custom is better in the abstract — it's whether the gap between what you do and what the product assumes is big enough to justify the cost.
If the missing piece is something you could change about how you work, change the process instead. Businesses sometimes pay six figures to automate a workflow that existed because of a decision nobody remembers making.
If you can't describe the process, you're not ready. Not because a supplier will refuse — plenty will happily take the project — but because an undefined process becomes a defined system with all the confusion baked in permanently.
If you're about to change the business significantly, wait until the shape settles. Building a system around a model you're in the middle of replacing is expensive in a way that only becomes obvious later.
When custom does earn its cost
When the thing that makes you competitive is exactly the thing standard software handles badly.
Wholesale tiers that depend on relationship history. Stock that exists in three states across two locations. Pricing rules a salesperson currently applies from memory. Approvals that follow your actual hierarchy rather than a generic one. Reports that answer your questions rather than the average customer's.
That's the test: does the awkward 20% of your process happen to be the part you win on? If yes, a system built around it stops being a cost and starts being an advantage. If it's just an inherited habit, fix the habit.
What the move actually involves
The build is the part people expect. The two that decide whether it succeeds are less glamorous.
Specification. Before anything is designed, the scope gets written down: what's built, what stays manual, what it costs, how long it takes. This is where projects are won or lost. A change on paper costs minutes; the same change after development costs weeks.
Migration. Your existing records get moved and reconciled against your old numbers. If the first report a manager opens doesn't match what they expected, trust evaporates and people quietly go back to the spreadsheet — and then you're paying for both.
Parallel running. The old way and the new system run together until the numbers agree. It feels like duplicated effort. It's the cheapest insurance in the project.
Training, by role. Not one session for everyone. The person raising purchase orders and the person closing the month need different things.
Start smaller than you think
The most common mistake is trying to replace everything at once.
Pick the part that hurts most — stock, or invoicing, or follow-ups — and solve that one properly. It proves the approach at a fraction of the cost, it gives your team a win before their patience runs out, and it tells you whether your supplier is any good while the stakes are still low. A system built module-first grows by addition instead of by rewrite.
We know this from both sides. We build these systems for clients, and we run two of our own: StockFlow, a retail ERP, and RestPOS, a restaurant point of sale — both in production, with paying users, uptime we're responsible for and support tickets that come to us. Living with our own architecture decisions is what convinced us that starting small is almost always right.
The honest summary
If your business runs on one spreadsheet and three people, keep it. It's the correct tool.
If two versions of the truth exist, if one person's memory is load-bearing, if reports arrive too late to use — you've crossed the line, and every month you wait costs more in reconciliation time than it feels like it does.
And if you're somewhere in the middle, the useful next step isn't a demo. It's writing down how your business actually works. That document is valuable whether you build anything or not — and any supplier worth hiring will ask for it anyway.