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.
Top comments (0)