We tracked every lab sample on foot for a month before writing any code

Before KantaHub was software, it was a month of following blood samples through a hospital lab with a pen and paper. Here is why we started there, and what it taught us about building for hospitals.

I was the phlebotomist who drew the blood. When a result came back late, I was also one of the people who heard about it from the ward. So in April 2025, before writing a single line of code, I spent a month tracking every sample at Nakasero Hospital's laboratory by hand: on foot, with pen and paper, from the moment it was drawn to the moment a result went out.

Why not just build the dashboard?

Because nobody could tell me where the time went. Everyone had a theory, and 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 wasn't visible.

Then the software

Only then did we build a system, and its 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. It went live in the hospital laboratory, and turnaround time improved by 20–40%.

That system is where KantaHub started. Our CTO had already built the lab's quality-control monitoring before he joined us, and between the two we had something rare: software shaped by people who had worked inside the exact workflow it serves.

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 lab can be busy and slow at the same time. What matters is where samples wait.
  • Build for the people on shift. Lab managers and biomedical engineers are the users, under time pressure, at the end of long shifts. That is who KantaHub is designed for.

We still work this way with every client: understand the operation first, then write the software that fits it. If your team runs on handovers, paper and spreadsheets, we'd like to hear how it works today.

← All posts

Ready to build something real?

Tell us what you're working on. We'll show you how we'd approach it.