For a long time, I thought building a bigger product meant building a better product.
More roles.
More features.
More users.
More institutions.
More possibilities.
After my GCE Advanced Level examinations ended in July 2026, I returned to my healthcare software project with that mindset beginning to change.
The project had already gone through several versions.
It had started as eHealth.
It later became a laboratory management system.
Then I expanded the idea into a much larger hospital management platform.
Technically, I was building more than ever before.
But I had a problem.
I was trying to solve too much at once.
A hospital is a huge problem space
The more I researched, the more obvious it became.
A hospital is not one workflow.
It is an ecosystem of workflows.
Doctors have their own needs.
Nurses have different responsibilities.
Laboratories operate differently.
Administration has its own processes.
Patients interact with the system differently.
Finance introduces another layer.
Trying to build everything at once meant constantly making assumptions about problems I didn't fully understand.
So I asked myself a simpler question:
Where do I have the clearest connection to the problem?
The answer was the laboratory.
My original experience as a patient had included a laboratory visit.
My uncle had later given me insight into laboratory operations.
I had already attempted to build software specifically for a laboratory.
There was a thread running through the entire journey.
I had just spent too long trying to make the problem bigger than it needed to be.
I decided to reduce the scope
Instead of building for every department in a hospital, I decided to focus on laboratories.
That meant removing features.
Removing roles.
Removing workflows that didn't belong to the core problem.
And honestly, that was one of the most important decisions I made.
Because reducing scope didn't make the project less ambitious.
It made the ambition clearer.
Instead of asking:
“How can I digitize an entire hospital?”
I could now ask more specific questions:
“How does a laboratory manage patients?”
“How does a test move through the workflow?”
“Who needs access to what?”
“How can results be managed more efficiently?”
“What information does the laboratory actually need?”
These were better questions.
And better questions led to better decisions.
Focus became a feature
One thing I have learned from this project is that focus is not the absence of ambition.
Sometimes, focus is how ambition becomes useful.
A smaller market can be easier to understand.
A narrower workflow can be easier to validate.
A specific user group can give better feedback.
And a focused MVP can reach the real world faster than a giant platform that tries to do everything.
That decision changed the direction of my project.
I began rebuilding with a clearer purpose.
The hospital platform was slowly disappearing.
In its place, something more focused was emerging.
A laboratory management system designed around the workflows I had spent years gradually learning about.
And this time, the project finally had a name that matched where the journey was going.
nanoLabs.
But choosing a name and building an MVP was only the beginning.
The next challenge was much harder.
Would anyone actually use it?
Top comments (0)