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

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.