5 signs it’s time to rebuild
By Steele Consulting
Every business has one. The Excel workbook that started as a personal tracker for one person and somehow became the source of truth for something the business actually runs on. The master pricing sheet. The commission calculator. The customer onboarding template. The inventory reconciliation. The report the CFO’s team rebuilds by hand every month.
Nobody ever decided to make a spreadsheet do this. It just gradually became load-bearing.
In our 24 years at Steele Consulting building custom software, one of the most common origin stories for a project starts with a business owner realizing that a spreadsheet they’ve never thought much about has quietly become infrastructure. Usually the realization comes at a bad moment: the person who maintains it goes on leave, the numbers come out wrong for a critical decision, or a new hire spends two weeks trying to figure out what any of it means.
Spreadsheets are extraordinary tools. They’re also, unmistakably, tools — not systems. When they cross that line, the risk profile of the business shifts, and most owners don’t notice until it costs them.
Here are the five signs that a spreadsheet has become a system. If you see more than two of them in the same workbook, you’re not looking at a spreadsheet anymore. You’re looking at unmanaged production software.
Sign 1: Multiple copies exist and nobody’s sure which is current
The spreadsheet has been copied. Renamed. Copied again. Somebody appended “_v2” to a filename. Somebody else appended “_v2_FINAL.” A third person is now working from something called “_v2_FINAL_use_this_one_actually” and is not confident.
Version drift is the earliest and most reliable sign that a spreadsheet has outgrown its container. Real systems have a single source of truth by design. Spreadsheets that end up in email attachments, shared drives, and personal desktops have a source of truth by accident, and accidents don’t scale.
If you’re not sure which copy of a spreadsheet is current, you have a version control problem — and version control is a software problem, not a spreadsheet problem.
Sign 2: One person understands it
You know the person. They built it. Nobody else fully knows how it works. The formulas reference other formulas that reference cells six tabs over. There are macros. There might be a Python script somewhere. When that person is on vacation, the finance close is late. When they’re at their desk, they’re routinely interrupted with questions nobody else can answer.
This is the exact Key-Person Cost we wrote about in The Real Cost of an Underbuilt Tech Team, in miniature. The risk doesn’t shrink with time. It grows with it — the longer that one person maintains the spreadsheet, the more the institutional knowledge concentrates around them, and the more expensive their eventual transition becomes.
A spreadsheet that only one person can operate isn’t documentation. It’s a liability wearing the disguise of a workbook.
Sign 3: It’s being manually reconciled with other systems
Once a week, once a day, once an hour — someone copies data from the CRM into the spreadsheet, or from the spreadsheet into the accounting system, or from the ordering system into three different tabs. Someone updates fields in one place because another system got updated somewhere else.
That reconciliation is now a business process. It has a schedule. It has an owner. It has a failure mode when the person who does it is out. It’s just being executed by a human because the systems aren’t integrated.
Manual reconciliation is a Friction Cost from the DRIFT framework we described in our tech debt post — the hours of workaround labor spent working around bad system boundaries. The moment you realize a spreadsheet exists to bridge two other systems, the honest question is whether the bridge should be code.
Sign 4: It breaks silently
A cell reference gets deleted. A formula gets overwritten with a hard-coded value. Someone types over a header. The spreadsheet keeps opening. The output still looks right at a glance. But the numbers have been wrong for two weeks, and nobody knows until somebody notices the totals don’t match the bank statement, or a report used in a board meeting turns out to have been drawing from the wrong column.
Real systems fail loudly. Spreadsheets fail silently. There’s no error log. No unit tests. No monitoring. No alert when something changes. Every edit is a potential undetected bug, and the more people who touch the workbook, the more of those there are.
If your spreadsheet has been quietly wrong at least once in a way that affected a real decision, that’s not a fluke. That’s the natural failure mode of using a spreadsheet as a system. It will happen again.
Sign 5: It’s touching customers, revenue, or compliance
This one changes the stakes fundamentally. A spreadsheet that tracks internal team lunches can be brittle without much consequence. A spreadsheet that decides how much to invoice a customer, or which orders ship this week, or how much to withhold for taxes — that’s a different risk profile entirely.
The moment a spreadsheet touches revenue, customers, or compliance, the tolerance for silent failure drops to zero. And spreadsheets, no matter how well-built, do not offer zero tolerance for silent failure. That’s what real systems are for.
If any of the numbers in your spreadsheet directly become invoices, payments, tax filings, or customer commitments, the spreadsheet has quietly become a piece of financial infrastructure. It should be evaluated as one.
What to do when you see the signs
Seeing two or more of these signs doesn’t automatically mean “custom software.” It means the workbook has outgrown its container and it’s time to actually decide what to do about it. That decision breaks into the same three options we wrote about in Build, Buy, or Bend:
- Buy — replace the spreadsheet with an off-the-shelf tool designed for its job. This is usually right when the workflow is industry-standard (commissions, inventory, timesheets) and a mature tool exists.
- Bend — invest in the spreadsheet itself. Move to a shared workbook with proper access controls, add data validation, document the formulas, assign clear ownership. This is right when the workbook has 12 more months of life and the fix is bounded.
- Build — rebuild the workflow as proper software, with authentication, audit trails, integrations, and error handling. This is right when the workflow is genuinely specific to your business and going to be around for years.
The mistake most businesses make isn’t picking wrong between the three. It’s not picking at all. The workbook keeps growing. The version drift keeps compounding. The one person who maintains it accumulates more institutional knowledge. And one day something breaks in a way that costs real money, and the conversation about what to do about the spreadsheet finally starts — usually a year later than it should have.
The graceful exit
When you do decide to move off a spreadsheet, the transition itself is a project. A few patterns are worth flagging:
- Don’t try to move the whole workbook at once. Break it into the workflows the workbook actually supports and migrate them one at a time.
- Run the old and new systems in parallel for at least one cycle. Match the outputs. Fix the discrepancies before you cut over.
- Document what the spreadsheet actually does, not what someone thinks it does. Every workbook that’s been around for more than a year has features people have forgotten about and edge cases that only appear at quarter-end.
- Assume you’ll find undocumented business rules embedded in the formulas. The spreadsheet has been making decisions for years that aren’t written down anywhere else. Surface them before you cut over, or you’ll rebuild them by accident.
How we approach this at Steele Consulting
More Steele projects have started as “we need to get off a spreadsheet” than any other origin story. Sometimes the answer is a full custom build. Sometimes it’s an integration layer that keeps most of the workflow but replaces the fragile parts. Sometimes it’s a recommendation to move to an off-the-shelf tool we didn’t build and won’t earn a dollar on.
We’ll tell you which one fits — and if the honest answer is that the spreadsheet still has another year in it with some careful cleanup, we’ll tell you that too. Not everything that outgrows a spreadsheet needs to become custom software immediately.
If you have a workbook that’s been quietly running your business and you’re not sure whether it’s time to rebuild it, that’s the conversation we’re happy to have. Reach out and we’ll walk through the five signs with you.