Almost every company we work with has one. A single file, usually named something like Tracker_v4_FINAL.xlsx, that started as one person's way of keeping track of something and is now the only place that information exists.
It gets talked about as a problem. It shouldn't be, at least not at first. That spreadsheet exists because somebody needed an answer and didn't wait six months for a budget cycle to get one. It cost nothing, it shipped the same afternoon, and it was shaped exactly like the actual work instead of like somebody's idea of the work. Most software never manages all three.
The interesting part is what happens next.
The tell isn't size
People assume the moment to replace a spreadsheet arrives when it gets too big. It doesn't. We've seen 60,000-row files that were completely fine and 300-row files that were a genuine business risk.
The real tell is behavioral. Someone opens the file and gets careful. There's a column nobody sorts because sorting once broke everything. There's a tab people were told not to touch. Changes get made by messaging one specific person rather than by editing. When a tool starts producing that kind of caution, it has stopped being a tool and become a liability that everybody is quietly managing around.
The question isn't how many rows it has. It's how many people are afraid of it.
What breaks, specifically
Four things, more or less in this order.
Two people at once. The first real crack. Shared editing helps, but two people reconciling the same numbers in the same minute produces a file that is confidently wrong rather than obviously broken, and nobody can tell which version won.
No history. A number changed. It's now different than it was last quarter. Who changed it, when, and on what basis — the file has no opinion on any of that. This tends to be discovered during an audit, a dispute, or a conversation with a customer who has their own records.
Nothing checks anything. Somebody types a date in a quantity column. A formula silently ranges over one row too few after an insert. Bad data in a spreadsheet doesn't announce itself; it just quietly participates in every total downstream until someone notices the year is off.
One person understands it. The most expensive one. Somewhere in that workbook is logic nobody has ever written down, and it lives in the head of one person who built it four years ago. When they take two weeks off, the reporting takes two weeks off with them.
Keep the shape of the work
The failure mode when replacing one of these is building the system somebody wishes the business ran on, rather than the one it actually runs on. The spreadsheet has years of real-world edge cases baked into it — the customer who gets billed differently, the product line with its own rules, the manual override at month end. Those look like mess. Most of them are load-bearing.
So the first job is reading the file, not designing a replacement. Every strange column is a question: who put this here, and what went wrong that made them add it? Half the answers reveal a real requirement. The other half are dead weight from a process that ended in 2021, and dropping those is where a lot of the value is.
Replace the file, keep the export
Something we've learned the hard way: build the export on day one, not at the end.
People who have run a business out of a spreadsheet for years do not want to be told they can never have a spreadsheet again. They want the ad-hoc question answered on a Friday afternoon without filing a request. Give them a proper system for the daily work — with permissions, validation, and a record of who did what — and a clean export for everything else. Fighting that instinct is how internal tools end up unused, with the old file still open in the next tab.
The version of this that works is boring. The data lives in one place with rules around it. Two people can work at once. Every change has a name and a timestamp attached. And the person who built the original workbook can go on vacation without the reporting going with them.
If reading this made you think of a specific filename, that's the one. It's usually worth a conversation before it's worth a project — the useful first question is what that file would cost you on the week it finally breaks. (Some of the systems we've built to replace one.)