They tend to be the same ones.
I was never really making spreadsheets. I was consulting, and the spreadsheet was just what the room had.
For years, I worked in situations where somebody needed a process or a system now: a forecasting build, an ERP workaround, consolidated reporting, covenant reporting a lender was waiting on, some operational process that wasn't working the way it needed to.
Usually, there was software that could theoretically solve the problem. The real answer might have involved a new ERP, a planning platform, a data warehouse, a reporting layer and a long implementation.
Nobody had a year.
So we built what was needed with the tools we had.
A lot of the time, that meant Excel and the Microsoft ecosystem around it. And I'll still defend those tools. Excel could connect to almost anything and become almost anything. Most businesses are sitting on considerably more capability than they realize.
Over time, though, I noticed something.
It didn't really matter whether the client was running NetSuite, QuickBooks Online, Workday or something else. The specific software changed, but the problems kept looking familiar.
The standard system got you most of the way there. Then there was the last 10 or 20 percent — the part specific to how that particular business actually operated.
That's where everything got messy.
Someone exported something. Someone maintained another spreadsheet. Somebody had a process that only they understood. Data moved between systems manually. Reporting depended on three people remembering exactly what to do every month.
The gaps weren't really software problems. They were operating problems that the software didn't understand.
For a long time, Excel was the best way to close those gaps. At various points I had effectively built budgeting systems, reporting systems, databases and little ERPs inside of it.
But there was always a limitation.
What I had built was an impression of software.
It worked extremely well as long as the people who understood it stayed close to it. But handing it off could prove difficult, and that quietly reduces the impact of having a good process. To build everything people were asking for, I often had to push Excel — and the tools around it — to their limits, which was well beyond the knowledge base of my clients.
The knowledge was embedded in the build, and the build was hard to turn into a product.
So every customization stayed more or less a one-off.
That is the part that has changed.
The combination of modern development platforms, AI-assisted development and better infrastructure has dramatically lowered the cost of turning that kind of process knowledge into actual software.
The things I spent years building in constrained environments — understanding the logic, finding where a process binds, connecting systems and designing around the way people actually work — can now be deployed as the real thing.
That's the idea behind Harrison Foundry.
We start with an operating problem, not a category of software.
Track Law Time started with the gaps in how small and midsize law firms manage time, billing, matters and the business of the firm. Track Billed Time applies a similar idea to other professional services businesses. Bench Briefer came from another very specific legal workflow. Cap Rate Parking came from an entirely different operating problem in commercial real estate.
Different industries. Different users. Different software.
But the pattern is remarkably similar:
There is a gap between what the standard system does and what the business actually needs to do.
For most of my career, the answer was to build a workaround.
Now we can build the software.
If your business has one of those gaps, I'd genuinely like to hear about it.
