From Humla to Japan: What Building an Open-Source Project Taught Me About Starting With Very Little

I never imagined that a small laptop in a remote village in Nepal would eventually lead me to building an open-source project in Japan.

I'm 22, originally from Humla, a remote district in Nepal. My parents are farmers, and growing up, we didn't have many financial opportunities.

But I was always curious about computers.

The laptop that changed my direction

When I was in grade 10, my parents promised to buy me a laptop if I did well in my final examinations.

I studied hard, passed, and they kept their promise.

It wasn't an expensive laptop, but it opened a completely new world for me.

I started exploring programming, websites, and technology. I studied computer science in grades 11 and 12, and eventually developed a dream of continuing my IT education in Japan.

Getting there was not easy.

My family had to borrow money to make it possible. After arriving in Japan, I spent two years studying Japanese while working night shifts at a convenience store.

I had to manage my school fees, rent, transportation, and daily expenses.

I paid approximately ¥2 million in language-school tuition.

After graduating, I entered an IT engineering vocational school.

I thought this would be the beginning of my journey into professional software development.

But reality has been more complicated.

When your plans don't match reality

I came to Japan because I wanted to become a software developer.

Finding an IT job as an international student can be difficult, and recently I've been encouraged to consider other career paths, including caregiving, hotel work, and restaurant jobs.

I understand that people are trying to help me find a stable future.

But software development is what I've spent years learning and working towards.

At the same time, I have financial responsibilities. My family borrowed money for my education, and returning to Nepal without a plan isn't a simple decision.

I've started asking myself an important question:

What if I could build a career around creating software instead of waiting for someone to give me an opportunity?

That question has pushed me to take my personal projects more seriously.

Building my first open-source platform

I've been working on a project called Critique.

The original idea came from something I noticed about independent developers.

People spend weeks or months building projects, but getting useful feedback can be surprisingly difficult.

Likes and generic comments don't always tell you what is wrong with your product or what you should improve.

I wanted to experiment with a simpler approach:

• Share a project.
• Ask one focused question.
• Receive honest feedback from real people.

That's the idea behind Critique.

I started building it myself and gradually opened the codebase to other developers.

I've been learning about backend development, frontend development, testing, analytics, GitHub maintenance, contributor onboarding, and product design along the way.

It's been a much bigger learning experience than simply writing code.

Our first small milestones

Critique is still very early, but we've made some progress:

• 15 GitHub stars.
• 40+ contributors.
• 40+ repository forks.
• 13 registered platform users.

These numbers aren't huge compared with established open-source projects.

But for someone building independently, they mean a lot.

Seeing other developers inspect the code, open pull requests, report issues, and suggest improvements has been one of the most encouraging parts of this journey.

It has also taught me that creating an open-source project and building an open-source community are two very different challenges.

The numbers that made me rethink the product

I recently started looking more closely at our analytics.

Here is what we've recorded so far:

One thing immediately caught my attention.

People were interested enough to start writing feedback, but relatively few submissions were being completed.

That made me realize something:

Building features isn't necessarily the same as solving users' problems.

Maybe the form is too long.
Maybe registration creates too much friction.
Maybe the questions aren't clear enough.
Maybe there are technical problems.

I don't want to add features just because I think they sound useful.

I want to understand why people leave, what frustrates them, and what would make them return.

I've already received suggestions from developers about improving project descriptions, making project links easier to find, showing example questions, and simplifying the feedback process.

Those suggestions have been more useful than simply hearing that the idea is good.

What I'm learning about building in public

There are a few lessons I've learned so far.

1. Building the product is only the beginning.

Getting people to discover it, understand it, trust it, and actually use it is a completely different challenge.

2. Open source needs good contributor experiences.

Simply adding a good-first-issue label isn't enough. Issues need clear descriptions, expected behaviour, relevant files, and acceptance criteria.

3. Analytics are useful when they lead to questions.

A number alone doesn't explain user behaviour. You need to investigate what happened and why.

4. Honest criticism is more valuable than empty encouragement.

Some of the most useful improvements I've made started with someone telling me something wasn't working.

5. Progress doesn't always look impressive from the outside.

Sometimes progress means fixing one frustrating bug, improving a confusing page, or helping a first-time contributor understand the codebase.

What comes next?

I want to keep improving Critique, make the feedback experience easier, and build a community where developers genuinely help each other.

I also hope to connect with more developers and eventually work with people on remote software projects.

My long-term dream is to build a small team, create useful software, and eventually return to Nepal to work remotely from a quiet little workspace.

I don't know exactly how I'll get there.

I don't know whether this project will become a successful business.

But I know that building it has already taught me things I couldn't have learned from a classroom alone.

And I want to keep learning.

A question for other developers

For those of you who have built open-source projects or launched your own products:

What was the hardest part of getting your first real users and turning their feedback into a better product?

Was it discovery, trust, onboarding, retention, or something else?

I'd genuinely like to learn from your experiences.

Thanks for reading.

Disclosure: I used AI assistance to help organize and improve the English in this article. The experiences, project details, and opinions are my own.