I Built a Laboratory Management System Before I Fully Understood the Laboratory

The first time I tried building healthcare software, I was solving a problem from the perspective of a patient.

This time was different.

My uncle owns one of the biggest medical laboratories in Cameroon, and after one of our conversations about his work, I started looking at the problem from a completely different perspective.

I had already gained considerably more experience as a developer.

I had worked with real products, learned from other developers and become more comfortable with modern application development.

So I decided to build him a system.

This wasn't another small experiment.

I wanted to build something his laboratory could actually use.

I started building with React and Firebase. I implemented authentication and began creating different roles and workflows for the people who would interact with the system.

The more I built, the more excited I became.

I remember looking at the application and thinking:

This could actually work.

But I was still making an important mistake.

I knew how to build software.

I didn't yet understand the laboratory well enough.

The difference between building software and solving a problem

From the outside, a laboratory workflow can appear simple:

Patient → Test → Result.

But that's nowhere near the full picture.

There are people involved in registration, sample collection, testing, result entry, verification, approval, reporting, inventory and administration.

Different people have different responsibilities.

Different actions require different permissions.

And a system that ignores those realities can become more of a burden than a solution.

My uncle helped me understand that.

He gave me insight into how the laboratory actually operated and pointed out things I hadn't considered when designing the system.

That changed the way I thought about the project.

I began realizing that I couldn't simply build what I thought a laboratory needed.

I had to understand what a laboratory actually needed.

So I went back to the application.

I changed things.

I removed things.

I added new workflows.

I adjusted the way different users interacted with the system.

Eventually, I had something much better than my original eHealth project.

A basic laboratory management system.

And I genuinely believed I was finally getting somewhere.

But there was a problem I couldn't solve with code.

Life was about to interrupt the project again.

And for the second time, something I had spent so much time building would end up sitting on a shelf.

I just didn't know it yet.