The spreadsheet phase is normal — respect it
Almost every business we talk to runs at least one critical process on a spreadsheet: quotes in one workbook, the job tracker in another, stock on a tab that only one person fully understands. And honestly, the spreadsheet earned that place. It is the cheapest prototype ever invented — zero build cost, no training, flexible enough to absorb whatever the process throws at it this week. When one person runs a repeatable process, it is genuinely the right tool, and replacing it would be theatre.
The trouble starts when the sheet quietly becomes a system of record: more people editing it, other work depending on its numbers, and nobody able to say who changed what or when. At that point you are running a business system with no owner, no permissions, no validation and no audit trail. The failures that follow are well documented — mislinked budget cells, hidden worksheets leaking personal data, a regulator asking how a number was reached with nobody able to reconstruct it — as one thorough teardown of spreadsheet failures catalogues. The sheet did not get worse. The job it is doing got bigger.
Seven signs the process has outgrown the sheet
No single symptom tells the whole story, but these seven are the ones we hear before almost every replacement project.
More than one person edits the same sheet, and an overwrite has already cost you data — or an argument about whose version was right.
The same information is typed into two or three places: the job sheet, the diary, the invoice. Someone's actual job is reconciling the copies.
One person owns 'the master file', and the process stalls when they are on leave. If the business cannot survive their holiday, it does not have a system; it has a person.
Simple questions need a favour. 'How many orders are late this week?' should not require a pivot table and the one colleague who knows how the file was built.
Permissions are all-or-nothing. You would like a contractor to see only their jobs, but sharing the sheet means sharing everything — including the payroll tab.
The process has left the desk. Field staff, phones, customers waiting for an answer — and the sheet is unusable or invisible there.
There are formulas nobody dares to touch, and everyone works around them instead of fixing them.
If three or more sound familiar, it is worth scoping a replacement. If even one of them touches money leaving the building or a regulator's question — invoices, payroll, compliance returns — treat it as urgent. Pooled field-audit research keeps finding the same uncomfortable pattern: across dozens of operational spreadsheets examined cell by cell, errors turned up in the large majority of them, a finding documented with its sources here. A one per cent cell error rate sounds trivial until the sheet holds a thousand cells.
Fix the process before you automate it
Bill Gates wrote in Business @ the Speed of Thought (1999) that 'the first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.' A quarter-century of automation projects has not dented it: automating a messy process produces the mess faster, with more confidence, and now it is harder to unwind.
So before any build, map the process as it actually runs — not the documented version. What goes in, who touches it, what comes out, where the exceptions go. The map almost always surfaces steps the sheet was hiding: approvals that happen over chat, figures retyped from an email thread, a Friday ritual nobody can explain. Fixing those first is often half the value of the whole project.
And one gate to respect: if the process changes every week, it is not ready to automate. A system encodes rules; if the rules are still being invented, you will pay to rebuild them monthly. Stabilise the process first, then systematise it.
Buy first; build when the fit breaks
Most common workflows already have good off-the-shelf answers: CRMs, project-management tools, booking systems, inventory apps. If one covers the workflow without contortion, buy it. We have talked people out of custom builds for exactly this reason, and our guide to the custom-CRM-versus-off-the-shelf decision walks through that call for customer systems specifically.
Custom software earns its keep in three situations. First, the process is how you win: bending it to fit a generic tool would make you worse at what you do. Second, you are paying for five subscriptions and gluing them together with manual work — at some point the glue costs more than the system. Third, customers or partners need to log in and see their own data: a client portal, an order tracker, a quote history. Spreadsheets cannot do that safely at all.
What the replacement actually looks like
It is not a bigger spreadsheet. It is one record of the thing — the job, the order, the case — entered once, with the rules attached: validation at the point of entry so bad data cannot get in, permissions by role so each person sees only their slice, and an audit trail of who changed what, when.
Digital links replace retyping. The system talks to your accounts package directly instead of someone copying figures across at month-end. Those connections are usually built through API integrations, and they are the part of a build that most moves the scope — which is why the spreadsheet that feeds your accounts is the first one to examine.
A concrete example from our own work. BisCom Sweden AB, an information-services company, depended on data that was publicly available on the web but scattered and slow to gather by hand — repetitive work that left their information out of date by the time it was compiled. We built a custom extraction pipeline that collects the data automatically and prepares it the way their internal processes need it, and we still supply updated data every month. The manual collection work is gone; the team works from prepared data rather than ad-hoc gathering.
One design principle worth stealing from successful replacements: keep the new screens close to the vocabulary of the old sheet — the same column names, the same status words the team already uses. The team already knows how to read it. The system should feel like the sheet grew up, not like a new job to learn.
Scope it as one process, not a platform
Do not rewrite everything at once. Pick the single most painful process — the sheet causing the most errors or eating the most hours — and replace that first. Map every field, every formula, every manual step the team actually performs. Build to that map, then run the old sheet and the new system in parallel for two to four weeks so the team can compare and catch whatever the map missed. Then retire the sheet and move to the next process.
Scope honestly and keep it small on purpose. A focused first phase goes live in weeks rather than quarters, and the price moves with integrations and edge cases — our cost guide explains how to read a quote for this kind of work. And keep Excel for what it is genuinely good at: one-off analysis, quick models, simple lists owned by one person. The goal was never to kill the spreadsheet. It was to stop running the business on one — which is where our custom software development work always starts: which process, what does it cost you today, and what is the smallest system that fixes it.