When I started building my first healthcare project, I thought the hardest part would be writing the code.
I was wrong.
The hardest part was understanding what I was actually trying to solve.
In 2024, I had just been admitted to a public hospital in Limbe after being diagnosed with a bacterial infection. While I was there, I experienced some of the frustrations that eventually made me start thinking about healthcare software.
After returning home, I opened my laptop.
I decided to build something.
At the time, I was primarily working with Flutter, and my understanding of backend infrastructure was still developing.
I had used mock data before, but I wanted to make the project feel more real.
That's when I started experimenting with Firebase and Firestore.
The problem?
I barely understood what I was doing.
I knew I needed authentication.
I knew I needed somewhere to store patient information.
I knew different parts of the application needed to communicate with each other.
But knowing what you want a system to do and understanding how to architect that system are two completely different things.
So I started with what I knew.
I built screens.
I created flows.
I connected things together.
I tested.
I broke things.
I searched for solutions.
And I repeated the process.
Eventually, I called the project eHealth.
Looking back, it was a very ambitious project for where I was technically.
But it taught me something that has stayed with me ever since:
You can build a technically impressive application and still be solving the wrong problem.
I understood my experience as a patient.
I didn't understand the experience of the people operating the system.
I didn't know how nurses actually received information.
I didn't understand how laboratory technicians handled samples.
I didn't understand how results moved through a laboratory.
I didn't understand the operational constraints.
I was essentially designing a healthcare system from the perspective of someone who had used healthcare services.
That wasn't enough.
Eventually, I paused the project.
At the time, I thought I had simply failed to finish something I had started.
Today, I see it differently.
That first project wasn't the final product.
It was the beginning of my education about the problem.
And perhaps more importantly, it taught me that software development isn't just about knowing how to code.
You have to understand the people who will use what you build.
You have to understand their workflow.
You have to understand the environment.
And sometimes, you have to be willing to throw away something you've spent weeks building because your understanding of the problem has changed.
Years later, that lesson would become extremely important when I returned to this idea.
But I didn't know that yet.
At the time, I simply closed the project and moved on.
The next chapter would have nothing to do with healthcare.
DEV tags
