The spreadsheet wasn’t the problem

A few years ago a client walked me through the system they wanted to replace. It was a spreadsheet a sprawling, color-coded, slightly terrifying spreadsheet that one person had built and now quietly ran a meaningful part of the business. They were apologetic about it. “We know it’s embarrassing,” they said. “We need real software.”

So we did the thing we always do before agreeing to build anything: we asked what the spreadsheet was actually doing. And the more we looked, the more impressive it got. It encoded a decade of hard-won operational knowledge the exceptions, the edge cases, the “if this client, then that rule” logic that no off-the-shelf tool had ever handled. The spreadsheet wasn’t the problem. The spreadsheet was the requirements document, written in the only language the team had available.

The mistake everyone makes

The instinct, when you see a business running on a spreadsheet, is to treat the spreadsheet as the failure and the software as the cure. That’s backwards. The spreadsheet is usually a sign that the team understood their problem so well they built a working solution with the crudest possible tools. The failure isn’t the spreadsheet. The failure is everything around it the fact that it lives on one laptop, that only one person can change it, that it breaks silently, that it can’t scale past the person who made it.

If you replace the spreadsheet without first understanding why it works, you don’t get better software. You get worse software that’s harder to fix, because you’ve thrown away the one artifact that captured how the business really runs.

The spreadsheet was the requirements document, written in the only language the team had available.

What we did instead

We didn’t replace it on day one. We read it carefully, like a specification, because that’s what it was. We sat with the person who built it and asked why each rule existed. Most of them had a story, and most of those stories were the difference between software that holds up and software that gets worked around within a month.

Then we built the system the spreadsheet was quietly asking for: the same logic, but durable, multi-user, observable, and able to grow. We kept the spreadsheet running in parallel until the new system had earned the team’s trust. When we finally turned it off, nobody was nervous, because nothing about how they worked had been guessed at.

The lesson I keep relearning

When a client is embarrassed about their workaround, I’ve learned to get curious instead of agreeable. The workaround is where the real knowledge lives. The job isn’t to make it disappear it’s to give that knowledge a home that can survive the person who created it. Get that right and the software almost designs itself. Get it wrong, and you’ve spent six figures to build a worse spreadsheet.