The Excel Nobody Asked For
Someone on your team manually maintains a file no system generates, and half the operation now depends on it. It describes, in more detail than any requirements document, the software your company needed but never got built.
There’s an Excel file in your company that didn’t come from any system. Someone opens it on Mondays at nine, updates cells for an hour, and from it comes the number that sets the week’s course. It was started by a person who no longer maintains it, to solve something the platform didn’t show. Nobody approved it and nobody can do without it.

Much of that hour goes into verifying that the totals match what the system shows in another module, because when they don’t, you have to figure out which one is right. Nobody was assigned that task. It was solved by whoever was closest to the problem, and over time it became part of the role without ever appearing in any job description.
The Signs Your Week Has Already Shown You
Monday’s file isn’t the only case. Numbers don’t match between two systems, and someone checks them manually before they reach a meeting. Information arrives late because it depends on someone having the time to put it together. Every report has the format of whoever prepared it. And there are processes that stop when the person who knows how to do them is missing—the most uncomfortable signal because it doesn’t rely on any tool.
None of this was decided. It accumulated every time the system didn’t reach where the operation did, and someone had to solve it so the business wouldn’t stall.
Before Asking Your Team to Get Organized
Seen from management’s perspective, all this looks like an organizational problem, and the natural reaction is to ask the team to tidy up their processes. The team already did. What they did was build outside what the tool didn’t solve inside—the only way out when the system stops halfway through the operation. That work consumes hours every week and is paid through payroll, where you’ll never find it by searching the technology budget.
The business adapted to the software.
The Unwritten Manual of Your Operation
A requirement is written in a meeting, approved, and hopefully survives contact with reality. The fixes your team invented were born the other way around: they came from a real problem, were tested the next day, and were corrected until they worked. They’ve been operating for years without anyone replacing them, which is the toughest test a specification can undergo. There it is described, with more precision than in any document, what your operation needs and the tool doesn’t provide.

It’s worth translating it piece by piece. Monday’s Excel describes a requirement that was never solved. The step of copying data from one system to another is an integration nobody built, and the fact that it’s done manually every week indicates exactly between which two points it was needed. When everyone puts together the same report in their own way, what’s missing is a business rule that was never implemented, and the differences between versions mark where the disagreement lay.
You have the most accurate description of how your company operates. The problem is where it lives: in the heads of five people spread across three areas, sustained by habit and the memory of whoever has been there longest. Nobody wrote it down, nobody reviews it, and when one of those five leaves, they take a part with them.
Why This Wasn’t Considered Before
The answer to all of the above was always the same: building something custom was outside the budget for a company of your size, so the sensible thing was to adapt to what the market offered and absorb the difference with your people’s hours. That calculation has changed in recent years. The difference is that today the conversation starts with whether it makes sense, not whether you can afford it.

When to Stay Where You Are
Not every operation justifies custom software, and it’s worth saying so clearly. For billing, accounting, or expense tracking, a subscription solves it better and cheaper than anyone could building from scratch. The criterion for moving is how much your operation gets deformed to fit into the tool, and there neither the license price nor the size of your company says anything. And that misfit you’ve already measured without intending to: every parallel file your team maintains is a measurement.
What to Do With This Next Monday
None of what follows requires hiring anyone or buying anything, and all three things can be done with the team you already have. They also serve to eliminate options: part of what hurts today can be solved without developing anything.
Three filters before deciding to build
- 01Track for two weeks who spends time bridging gaps between systems, how much time, and what data that work produces
- 02Separate the symptoms that better configuration can fix from the ones no configuration will ever resolve
- 03Ask your current vendor whether their platform connects to the others you use so information updates on its own
What remains after those three filters is the only thing that justifies building your own.
The system is already written, just written by hand.
Comments 0
Be the first to comment.