Building the Software Was Easier Than Getting People to Trust It

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.