From Excel to a real-time dashboard

The starting point

When a client tells you “we have a few Excel files,” what they almost always mean is they have fourteen. And that three of those fourteen update at eleven at night, two are handled by someone who no longer works there, and one has been broken for six months but nobody wants to touch it because “everything’s in there.”

This story is about a client like that. A functional operation, but held up by habit and human memory more than by any system.

The diagnosis

Before proposing anything, I spent the first week just understanding. No code. No database diagram. No mockups.

I talked to the owner, to the person who filled in the spreadsheets every day, and to whoever reviewed the reports at month-end. Three different perspectives on the same problem, and three different definitions of what “the truth” meant.

That disagreement was the real project. The code came later.

The approach

Instead of promising to replace everything on day one, we split the project into three deliveries:

Weeks 1–2: A single source of truth. We migrated the data living in multiple Excel files into one database, with clear rules about who can change what.

Weeks 3–4: The minimal interface. We built only what they needed to replace the daily flow. Nothing more. None of “and we could also add…”. That phrase kills projects.

Weeks 5–6: The dashboard. With the data already clean and the operation already running on the new system, the reports practically built themselves.

What we learned

The client expected the project to be “building a system.” The real project was agreeing on what their own numbers meant.

That’s the part most technical proposals don’t account for, and it’s where projects get lost: not in the code, but in the definitions.

How I work

If your operation looks like this story, let’s talk. I won’t promise to replace your Excel in a week. I promise to understand why your Excel looks the way it does, and to build something that makes sense for your particular business.