We like spreadsheets. It’s worth saying that up front, because what follows can sound like a complaint about them, and it isn’t.
A spreadsheet is the most successful piece of business software ever made precisely because it lets a non-programmer build exactly the tool they need, in an afternoon, without asking anyone’s permission. That’s a superpower. The person in your business who built the master tracker did something genuinely impressive.
The problem is not that they built it. The problem is what it means when the business can no longer run without it.
Two kinds of spreadsheet
There’s the spreadsheet as a scratchpad — a quick model, a one-off analysis, a place to think. Those are healthy. Everyone should have a dozen.
Then there’s the spreadsheet as infrastructure. You know this one. It has tabs. It has a tab that references another tab that references a tab nobody remembers making. It has one person who understands the formulas and a quiet, shared dread about what happens when that person is on vacation. It gets emailed around as Tracker_FINAL_v7_use_this_one.xlsx. It is, functionally, your database, your reporting layer, and your operating manual — held together by cell references.
When a spreadsheet crosses from the first kind into the second, something specific has happened: your business has outgrown the software it’s paying for, and someone on your team built the missing piece by hand.
That’s not a failure. That’s a requirements document.
What the spreadsheet is telling you
Look at what the infrastructure spreadsheet actually does, and you’ll find it’s almost always one of a few things:
It joins data your tools won’t join. The CRM knows the customer. The accounting system knows the invoice. Neither will tell you margin by customer, so somebody exports both every month and matches them up in a sheet. The spreadsheet exists because two systems that should share a record don’t.
It enforces a process your tools don’t know about. There’s a column for “materials ordered?” and a column for “inspection passed?” with a conditional format that turns red. That’s a workflow. Your team needed a workflow and the software they were given didn’t have one, so they built it in cells.
It answers the question the dashboards can’t. The vendor dashboard shows you what the vendor thought you’d want. Your spreadsheet shows you what you actually want — which jobs are dragging, which crew is fast, what a week really cost. The gap between those two is the gap between generic software and your business.
Every one of those is a precise, already-validated specification for software. Your team has already done the hardest part of software design, which is figuring out what the thing needs to do. They just built it in the only tool that would let them.
Why this is a good problem to have
Here is the part that changed recently, and it’s the reason we’re writing this at all.
Five years ago, recognizing this signal didn’t help you much. Turning the master tracker into real software meant a development shop, a six-figure quote, a nine-month timeline, and a real chance of ending up with something that fit your business worse than the spreadsheet did. So owners looked at the sheet, understood exactly what it meant, and kept using the sheet. Rationally.
That math has changed. AI-native development — where the requirements are captured in plain language, the architecture is generated and verified from them, and engineers direct the build rather than hand-typing every screen — has collapsed the cost and the time. The build that used to be an enterprise project is now something a small or mid-sized business can commission, own outright, and have running in a matter of months.
Which means the spreadsheet has become something better than a warning sign. It’s a head start. The people who built it already know what the software needs to do, in more detail than any consultant could extract in a discovery phase. Our job is to sit with them, draw it, and build the thing they were always trying to build.
Where to look in your own business
If you want a quick read on where you stand, ask three questions:
- Is there a spreadsheet that, if it were deleted tonight, would stop work tomorrow?
- Does one person own it — and does anyone else understand it?
- Does it exist because two systems you already pay for won’t talk to each other?
If the answer to all three is yes, you don’t have a spreadsheet problem. You have a software specification sitting in a shared drive, and it’s a lot closer to a solution than it looks.