DEV Community: Mangi Lerine Laslie JR

What Happens When Your MVP Meets Its First Real Users?

Mangi Lerine Laslie JR — Sun, 30 Aug 2026 22:51:01 +0000

Building an MVP teaches you how to create.

Getting your first users teaches you whether you created the right thing.

That's the phase I'm approaching with nanoLabs.

nanoLabs is a Laboratory Information Management System I'm building to help medical laboratories manage their workflows digitally.

The product has reached the point where I'm preparing for its first five laboratory deployments.

And that changes how I think about development.

When you're building alone, it's easy to test according to your own assumptions.

You know where the buttons are.

You know how the workflow is supposed to work.

You know what every feature is supposed to do.

A new user doesn't have that context.

They don't know what you intended.

They only know what they experience.

That's why the next stage of development isn't simply about adding more features.

It's about observing.

What I'm testing

I'm paying particular attention to:

User roles and permissions
Laboratory workflows
Test and result processing
Patient result updates
Auditability
Authentication
Database response times
Error handling
Overall usability

The goal is to find problems before they become problems for a laboratory.

But I'm also preparing myself for something developers don't always talk about enough:

The product will probably change.

Real users will challenge assumptions.

Some features may need to be redesigned.

Some things I thought were important may turn out not to matter.

Other things I completely overlooked may become priorities.

And that's okay.

An MVP isn't supposed to prove that you have built the final product.

It's supposed to help you learn what the final product needs to become.

For me, these first five laboratories aren't just potential customers.

They're going to be part of the product-development process.

Their feedback, frustrations, questions and workflows will tell me what nanoLabs needs to become next.

So I'm not entering this phase expecting everything to be perfect.

I'm entering it expecting to learn.

The code got me here. Real users will show me where to go next.

BuildInPublic #SoftwareDevelopment #HealthTech #LIMS #StartupJourney #AfricanTech #Cameroon

My Next Technical Challenge Isn't Writing Code

Mangi Lerine Laslie JR — Sat, 29 Aug 2026 22:28:45 +0000

One of the biggest changes in my journey building nanoLabs is that my definition of "done" has changed.

Before, I would build a feature, test it myself and think:

It works.

Now I'm asking a much harder question:

Will it work when five different laboratories start using it?

That's a completely different standard.

nanoLabs is preparing for its first laboratory deployments, and that means I'm thinking less about adding features and more about reliability.

The focus right now is on the fundamentals:

Role permissions and switching
Test workflows
Result validation
Patient result updates
Auditability
Database performance
Authentication
Error handling
User experience

A system can work perfectly with one test account and still expose serious problems when multiple users interact with it.

That's why I'm trying to approach this phase less like:

"What feature can I build next?"

and more like:

"What could go wrong when someone actually depends on this?"

That mindset changes how you test software.

You start thinking about edge cases.

You start questioning assumptions.

You start testing workflows instead of individual buttons.

And most importantly, you start listening to the people who will actually use the product.

My immediate goal is not to build the biggest laboratory platform in the world.

It's much simpler:

Get nanoLabs into five laboratories, learn from what happens, and make the product better from there.

Five laboratories will probably teach me more about building healthcare software than another hundred hours of coding alone.

So that's where I'm heading next.

Less guessing.

More testing.

More feedback.

More iteration.

And hopefully, the beginning of real-world traction.

Building the Software Was Easier Than Getting People to Trust It

Mangi Lerine Laslie JR — Fri, 28 Aug 2026 22:46:35 +0000

Building nanoLabs has taught me that there are two completely different challenges in building a startup.

The first is technical:

Can you build the product?

The second is much harder:

Can you get real people to trust and use it?

I'm currently experiencing that transition while building nanoLabs, a Laboratory Information Management System designed for medical laboratories.

The product is no longer just an idea or a design.

There is an MVP.

There are workflows.

There are different user roles.

There is a system to test, correct and improve.

But that is where another type of work begins.

Software doesn't automatically create trust

As developers, it's easy to believe that if we build something useful, people will automatically use it.

Reality is different.

Potential customers may:

Ignore your messages.
Be too busy to respond.
Already use another system.
Be skeptical of a new product.
Want to see proof before giving you their trust.

And in healthcare-related software, trust becomes even more important.

You're not just asking someone to try a new interface.

You're asking them to consider changing part of how they work.

That means the code needs to work, but so does everything around the code:

The explanation.
The demonstration.
The onboarding.
The support.
The reliability.
And eventually, the results.
What I'm learning now

My work on nanoLabs is changing.

I'm still coding, but I'm also testing the system from different user perspectives and preparing it for real-world use.

I'm learning that the feedback loop cannot come only from me.

A developer can build based on assumptions for months.

One real user can point out something you completely missed in five minutes.

That's why I believe the next phase is just as important as the development phase.

The goal isn't to say:

"I built a laboratory management system."

The goal is to eventually be able to say:

"Laboratories are using it because it genuinely makes their work better."

I'm not there yet.

But that's exactly why I'm building in public.

To document what happens between the idea and the outcome—the bugs, the unanswered messages, the corrections, the meetings, the lessons and hopefully, eventually, the breakthroughs.

The code is being written. Now I'm learning how to get it into the real world.

From Building the Product to Preparing It for Real Users

Mangi Lerine Laslie JR — Wed, 26 Aug 2026 22:26:31 +0000

There is a big difference between finishing a feature and being ready for real users.

I'm learning that while building nanoLabs, a Laboratory Information Management System designed around the workflows of medical laboratories.

At the moment, much of my work is no longer about starting from zero. It is about testing the product as different users, finding what breaks, correcting workflows and asking whether the system is actually ready to be trusted.

That means looking closely at things like:

Role-based access and switching
Laboratory test workflows
Result validation and updates
Patient result visibility
Data synchronization
Audit trails and traceability
Authentication and database performance

A bug in a simple project can be annoying.

A bug in software designed for real laboratory workflows is different. It forces you to think carefully about reliability, permissions and what happens when multiple people interact with the same data.

My biggest lesson right now is simple:

An MVP is not the finish line. Sometimes it is the moment the real work begins.

I'm continuing to test, correct and refine nanoLabs while preparing to engage potential launch laboratories.

The code is only one part of building a startup.

The harder part is turning that code into something people can trust enough to use.

That is the phase I'm in now.

Still building. Still testing. Still learning.

BuildInPublic #HealthTech #LIMS #SoftwareDevelopment #AfricanTech

I Spent Three Weeks Rebuilding My Healthcare Startup Around One Problem

Mangi Lerine Laslie JR — Tue, 25 Aug 2026 22:26:15 +0000

After years of changing direction, I finally understood something about my product:

I didn't need more features.

I needed more focus.

The project had gone through several versions.

It started as an idea called eHealth.

Then it became a laboratory management system.

Then I expanded it into a hospital management platform.

Each version taught me something, but the hospital platform became too broad.

So I made a difficult product decision.

I removed things.

From everything to one problem

Instead of trying to build software for an entire hospital, I decided to focus on laboratories.

That gave me a much clearer product scope.

I could concentrate on laboratory workflows rather than trying to understand every department in a hospital.

It also changed how I researched.

I wasn't simply asking:

What features can I add?

I started asking:

What does a laboratory actually need?

That distinction changed the development process.

Three weeks of rebuilding

I spent roughly three weeks locked in on the product.

I reviewed the architecture.

I redesigned parts of the UI.

I reworked workflows.

I removed unnecessary functionality.

I researched laboratory operations.

I tested what I had built.

And I used AI as part of my development workflow to accelerate parts of the process while still reviewing and validating the output myself.

The goal wasn't to create a perfect system.

It was to create a usable MVP.

That distinction is important.

A product can stay in development forever if you believe every feature needs to be perfect before anyone sees it.

At some point, you need real users to tell you what you're getting wrong.

The MVP was finally ready for its real test

By the end of those three weeks, I had something I was comfortable putting in front of laboratories.

Not a finished company.

Not a perfect product.

Not a massive healthcare platform.

An MVP.

And that was enough.

Because the next stage wasn't about writing another thousand lines of code.

It was about validation.

Would laboratory directors understand the problem?

Would they trust the system?

Would they be willing to try it?

Would the workflows actually fit the realities of Cameroonian laboratories?

Those were questions that code alone couldn't answer.

So I stopped hiding behind development.

The next part of the journey would require something I hadn't done much of before:

Going out and asking people to use what I had built.

That was when building nanoLabs stopped being purely a development project and started becoming a startup experiment.

Why I Stopped Trying to Build Everything

Mangi Lerine Laslie JR — Mon, 24 Aug 2026 22:17:20 +0000

One of the biggest mistakes I made while building my healthcare software was believing that more features automatically meant more value.

At one point, I was building a hospital management platform.

It had multiple user roles.

Different departments.

Different workflows.

And a growing number of ideas.

Technically, it was exciting.

Product-wise, it was becoming a problem.

A bigger product gave me a bigger problem

The more I researched hospitals, the more I realized how much I didn't know.

A hospital isn't one system.

It's a collection of many complex systems and workflows.

You have:

Clinical workflows
Nursing workflows
Laboratory workflows
Patient management
Administration
Finance
Reporting
Inventory

Each one can become an entire product on its own.

And I was trying to build around all of them.

That meant constantly making assumptions.

The more I added, the more assumptions I had to make.

Eventually, I stopped and asked:

What problem do I understand best?

For me, the answer was laboratories.

Going smaller gave the product direction

The decision was simple.

I removed the goal of immediately building for the entire hospital.

I focused on the laboratory.

That gave me a much clearer product direction.

Instead of asking:

How do I build software for every hospital department?

I started asking:

How does a laboratory actually operate?

What happens when a patient arrives?

How are tests requested?

How do samples move through the workflow?

How are results entered, reviewed and released?

What information does the laboratory staff actually need?

These questions were more specific.

And because they were more specific, I could research them better.

Focus is not a lack of ambition

At first, narrowing the product felt like reducing the size of my ambition.

Now I see it differently.

Focus is what makes ambition executable.

A focused product can:

Reach users faster
Be easier to test
Receive clearer feedback
Solve a specific problem properly
Avoid unnecessary features
Develop a stronger product identity

That decision became one of the foundations of what is now nanoLabs.

The hospital platform I had imagined wasn't necessarily a bad idea.

It was simply too broad for where I was at the time.

I needed to understand one problem deeply before trying to solve ten.

So I chose the laboratory.

That decision changed the product.

It changed my research.

It changed the market I was targeting.

And eventually, it gave the project a new identity.

nanoLabs was beginning to exist.

The next challenge was turning that clearer idea into something people could actually recognize, use and eventually trust.

The Most Important Product Decision I Made Was Removing Features

Mangi Lerine Laslie JR — Sun, 23 Aug 2026 22:20:43 +0000

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?

When Someone Doubted That I Had Built My Own Software

Mangi Lerine Laslie JR — Sat, 22 Aug 2026 22:38:41 +0000

One of the strangest parts of building as a young developer is realizing that sometimes, people don't doubt your product first.

They doubt you.

After spending months building and rebuilding a healthcare platform, I finally had someone willing to help me take the idea to potential clients.

For me, that was a major step forward.

Until then, most of the journey had happened alone.

I built.

I researched.

I redesigned.

I fixed bugs.

And I kept trying to turn an idea that started after a hospital experience into something that could eventually be used by real healthcare institutions.

Then we found a potential opportunity with a hospital in Limbe.

But before we even got to the meeting, my marketer learned that the hospital already had a digital system.

That immediately created doubt.

And eventually, the doubt became bigger.

He started questioning whether the project I was showing him was really something I had built myself.

My GitHub became part of my evidence

I didn't argue.

I opened my GitHub.

The commit history showed something I couldn't explain in a single presentation:

time.

The project had not appeared overnight.

There were commits from different periods.

Changes.

Updates.

Different versions of the idea.

The history reflected what I had been doing for years: building, learning, stopping, returning and improving.

I showed him.

Not because GitHub commits are perfect proof of who wrote every line of code.

They aren't.

But because the history showed that this project had a journey.

It had evolved.

It had existed long before this particular conversation.

And as a young developer, that mattered to me.

When people look at your age first, sometimes you feel like you have to work twice as hard just to be taken seriously.

But proof doesn't always remove doubt

This was another difficult lesson.

Sometimes you can show someone the evidence.

You can explain the process.

You can answer their questions.

And they may still have doubts.

You cannot force someone to believe in you.

Over time, the messages became less frequent.

I reached out.

I sent updates.

I tried to keep the conversation alive.

Eventually, the person who had once been excited about helping me take the project to market stopped responding.

For a while, it felt like everything had collapsed again.

I had a product.

I had prepared presentations.

I had a potential direction.

Then I was back to being alone with the project.

What I learned about building in public

Looking back, I think this experience is one reason I now believe in documenting my journey.

If your work only exists behind closed doors, people only see the final product.

They don't see:

The first broken prototype
The old screenshots
The redesigns
The failed ideas
The commits
The late-night debugging
The versions you abandoned
The lessons that changed your direction

Documentation creates a record.

Not just of success.

Of process.

And I think that matters, especially for young developers.

I'm still learning this.

I don't have everything figured out.

But if someone doubts what I built today, I don't need to convince everyone.

I just need to keep building.

Over time, the work becomes part of the evidence.

My GCE Advanced Level exams were approaching, so I had to put the project aside again.

At the time, I thought that was another ending.

I didn't know that when I returned after my exams, I would come back with a completely different understanding of the problem.

And that one decision would eventually change everything.

I would stop trying to solve the whole hospital.

The First Time I Tried to Take My Software Beyond My Laptop

Mangi Lerine Laslie JR — Fri, 21 Aug 2026 22:23:06 +0000

There is a big difference between building software and trying to get someone to use it.

I was beginning to learn that.

By 2026, the healthcare project I had started years earlier had gone through several versions. What began as a simple idea inspired by my experience as a patient had evolved into something much bigger: a hospital management platform with multiple roles and workflows.

I had spent a lot of time building.

But most of that work had happened behind a screen.

Then I met someone who changed the next part of the journey.

I could build, but I couldn't do everything alone

One day, while I was at a friend's tech shop, I met a marketer.

We started talking.

I explained what I had been building and why I believed it could make a difference.

To my surprise, he liked the idea.

More importantly, he believed enough in what I was doing to offer to help me market it.

That was important to me because I was starting to understand something that many developers eventually learn:

Building the product is only one part of building a company.

You can write the code.

You can design the interface.

You can fix the bugs.

You can deploy the application.

But eventually, someone has to know it exists.

Someone has to understand why it matters.

Someone has to decide to trust you.

Those are completely different challenges.

So I started preparing.

Preparing for the real world

I worked on a presentation.

I did more research.

I tried to understand the healthcare market better.

And I started preparing for conversations with potential clients.

At that point, I thought I was ready.

But looking back, I was still making one mistake.

I had built a lot of the product based on:

My personal experience as a patient
Online research
Reading about healthcare technology
AI-assisted exploration
My own assumptions about how the system should work

I had information.

But information is not the same as experience.

I still didn't fully understand every internal workflow of the institutions I wanted to serve.

That would become important very quickly.

Then we found a potential client

My marketer helped create an opportunity with a hospital in Limbe.

For me, this felt like the moment the project could finally leave my laptop.

I had spent so much time imagining the system being used.

Now there was a possibility of showing it to a real healthcare institution.

I was excited.

I thought this could be the beginning of everything.

But before we even got to the meeting, my marketer learned something from someone connected to the hospital.

They already had a system.

That information changed the atmosphere.

Almost immediately, the question became:

Why would they need mine?

It was a simple question.

But it exposed a problem I hadn't fully prepared for.

I knew how to explain what I had built.

I hadn't yet learned how to clearly explain why someone should switch from what they were already using.

That is a product problem.

A business problem.

And a market problem.

Not a coding problem.

A lesson I still carry with me

That experience taught me that a good product isn't automatically a competitive product.

Before approaching a client, you need to understand:

What they currently use
What they dislike about it
What still works well
What problems remain unsolved
Why changing systems would be worth the effort
What makes your solution genuinely different

Building first and asking these questions later is expensive.

I didn't fully understand that then.

I was still learning.

And unfortunately, this potential opportunity didn't end the way I had hoped.

The doubt started growing.

My marketer began questioning whether I had truly built the project myself.

I showed him my GitHub history and commits to prove that this had been a journey I had been working on for years.

But sometimes, evidence doesn't change someone's mind once doubt has already taken hold.

Soon, the person I thought would help me take the project to market stopped responding.

And for the first time, I started asking myself a difficult question.

What if this entire project was going nowhere?

But sometimes, a setback forces you to stop.

And sometimes, stopping is exactly what gives you the perspective you were missing.

I didn't know it yet.

But the next time I returned to this idea, I would make one of the most important decisions of the entire journey.

I would stop trying to solve the whole hospital.

And I would focus on one place.

The laboratory.

I Rebuilt My Laboratory System Into a Hospital Management Platform — And Learned That Bigger Isn't Always Better

Mangi Lerine Laslie JR — Thu, 20 Aug 2026 22:46:55 +0000

During the Easter break of 2026, I returned to a project I had already paused twice.

The first version had started as eHealth, inspired by my experience as a patient in a public hospital in Cameroon.

Later, the idea became a laboratory management system after I got the opportunity to understand the problem from a different perspective.

Then my GCE Advanced Level examinations and circumstances around the onboarding process forced me to pause again.

But I couldn't leave it there.

So I opened the project again.

This time, I decided to think bigger.

Back to the original idea

My first idea had always been connected to hospitals.

So when I returned to the project, I started rebuilding it as a hospital management platform.

The idea was ambitious.

Instead of creating a system for one laboratory, I started imagining a platform where multiple hospitals could have their own digital environments.

Different users.

Different roles.

Different workflows.

Patients, doctors, nurses, laboratory staff and administrators could all have their place in the system.

Technically, it was the biggest project I had ever attempted.

And honestly, I was excited.

I had more experience than when I built my first version in Flutter.

I understood software development better.

I had better tools available.

And AI also helped me move faster through parts of the development process.

AI helped me build faster, but it didn't make the decisions for me

AI was becoming an important part of my workflow.

It helped me explore ideas, understand unfamiliar concepts and move faster through repetitive parts of development.

But I still had to make the important decisions.

I reviewed what was being built.

I handled sensitive parts carefully.

I tested workflows.

And I kept asking myself whether the system actually made sense.

That was important because a large healthcare platform can quickly become complicated.

Adding more features doesn't automatically create more value.

Sometimes, it just creates more things that can break.

The temptation to solve everything

At that point, I was thinking about a lot of possibilities.

Multiple hospitals.

More users.

More workflows.

More features.

A bigger market.

And, of course, a bigger business opportunity.

But there was a problem I hadn't fully understood yet.

Trying to solve everything can make it harder to solve anything well.

I was building something increasingly large before I had completely validated what part of the healthcare system I was best positioned to understand and serve.

The platform was growing.

But I was still learning.

I didn't know it at the time, but I would eventually have to make a difficult product decision.

I would have to reduce the scope.

Not because the hospital idea was impossible.

But because focus can sometimes be more powerful than ambition.

That lesson would eventually lead me back to laboratories.

And that decision would give the project a name that has now become a central part of my journey:

nanoLabs.

But before that happened, there was another chapter.

Another meeting.

Another attempt to take the idea beyond my laptop.

And another lesson waiting for me.

The next chapter was where the real test began.

The Second Time I Had to Pause a Project I Believed In

Mangi Lerine Laslie JR — Wed, 19 Aug 2026 21:08:17 +0000

One of the hardest things about building personal projects is learning that technical progress isn't the only thing that determines whether a product moves forward.

You can write the code.

You can fix the bugs.

You can improve the workflow.

You can get closer to deployment.

And still have to stop.

That happened to me with my first serious laboratory management system.

After building an initial version for my uncle's laboratory and receiving feedback that helped me better understand real laboratory operations, the system was improving.

I had a clearer direction.

The goal was to onboard the laboratory and continue improving the product based on real-world usage.

But the timing changed.

My GCE Advanced Level examinations were approaching, and the post-electoral insecurity also made the onboarding process difficult.

The project had to pause.

Progress isn't always technical

As developers, we often measure progress through things we can see:

Features completed
Bugs fixed
Commits pushed
Screens redesigned
Systems deployed

But products exist outside the codebase.

A project can be technically ready while the people, timing or environment around it are not.

That was an important lesson for me.

At the time, pausing felt like failure.

I had already gone through one healthcare project that I couldn't continue. Now, just when this new laboratory system was beginning to feel more real, I had to put it aside too.

But looking back, I understand that the pause gave me something important:

distance.

When you're building every day, it's easy to become attached to your decisions.

A pause can give you time to see the product differently.

By the time I returned to the project, I wasn't thinking exactly the same way anymore.

My skills had improved.

My understanding had improved.

And most importantly, my ambition for the product had changed.

The system was no longer just becoming something I wanted to build for one laboratory.

I was beginning to ask a much bigger question:

What if this could work for many?

That question would eventually lead me back to the project.

But not in the way I originally expected.

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

Mangi Lerine Laslie JR — Tue, 18 Aug 2026 22:36:46 +0000

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.