We followed the work on foot for a month before writing any code

Before writing a single line of code, I spent a month tracking every sample in one laboratory by hand: on foot, with pen and paper, from the moment it was drawn to the moment a result went out. I knew that environment from the inside, and I knew that when a result came back late, everyone had a theory about why.

Why not just build the dashboard?

Because nobody could tell me where the time went. Every theory blamed a different step. Software built on a theory would have measured the wrong thing very precisely.

Walking the route answered the question. By the end of the month I had a map of the pipeline and the exact points where samples waited: between collection and the lab, at handovers between teams, and in the gap before anyone knew a result was ready. None of it was anyone's fault. It just was not visible.

Then the software

Paper only goes so far. A computer replaced the notebook within days, followed by a month of spreadsheets and a first dashboard presented in slides. Then we built a system whose whole job was to make every step of that map visible in real time: where each sample is, how long it has been there, and which ones are running late. Turnaround time improved by 20 to 40 percent.

That system is where KantaHub started, and the habit behind it is how we build everything since.

What it taught us

• Watch the work before you model it. The most useful requirements document we ever had was a month of handwritten notes.
• Measure the delay, not the activity. A team can be busy and slow at the same time. What matters is where work waits.
• Build for the people on shift. The users are working under time pressure at the end of long days. Design for them, not for the demo.

We still work this way with every client: understand the operation first, then write the software that fits it. The longest wait is rarely where anyone guessed. If your team runs on handovers, paper and spreadsheets, we would like to hear how it works today.