DEV Community: Dinesh Bista

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

Dinesh Bista — Thu, 12 Nov 2026 16:16:25 +0000

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:

Event	Count
Unique visitors	512
Project-page views	302
Feedback starts	104
Successful feedback submissions	25
Submission attempts	80
Submission errors	33

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.

I Built a Place Where Developers Can Get Feedback That Actually Helps

Dinesh Bista — Sun, 08 Nov 2026 09:46:55 +0000

Building a project is one thing.

Knowing what to improve next is another.

That's the problem I wanted to solve with Critique.

I didn't want to build another platform where developers just share links, collect likes, and move on.

I wanted something more useful.

One project. One focused question. Real human feedback.

How it works

Share a project you're building.
Ask one specific question.
Let other developers explore it.
Get feedback from real people.
Use those insights to improve.

What I've learned

Building the platform was only part of the journey.

I've also been fixing real issues, improving security, reviewing contributions, and learning how to maintain an open-source project.

Recently, I recovered and merged a security improvement from an older contributor pull request. That was a good reminder that open source isn't just about writing new code. It's about valuing the work people contribute.

Want to help build it?

Critique is open source, and I'd love to welcome developers who are just getting started with open source.

You don't need to be an expert.

Bug reports, documentation improvements, testing, UI ideas, and code contributions are all welcome.

Website: https://critique.page

GitHub: https://github.com/BistaDinesh03/critique

One question for you:

If you could get honest feedback on one thing you're building right now, what would you ask?

I'd love to hear your question. Maybe Critique can help you find an answer.

I built another side project. But this time, I wanted honest feedback instead of "Looks good."

Dinesh Bista — Sat, 07 Nov 2026 03:29:21 +0000

Building a side project is exciting.

You spend nights coding, fixing bugs, improving the UI, and adding features.

Finally, you share it with someone and ask:

"What do you think?"

The answer?

"Looks good!"

And that's it.

No details. No suggestions. Nothing you can actually improve.

I've experienced this myself.

The problem isn't that people don't want to help.

Sometimes, we're just asking the wrong questions.

Instead of asking someone to review an entire product, what if we asked them just ONE specific question?

For example:

Is it clear what my product actually does?
Would you understand how to use this feature?
What would stop you from trying this?
What's the first thing you'd improve? That's the idea behind Critique, a project I've been building.

It's a free platform where builders can:

Share something they've built.
Ask one focused question.
Get honest feedback from real people.
Help other builders by sharing their own feedback. No AI-generated responses. No generic feedback scores pretending to understand your product.

Just people helping people build better things.

Try it here: https://critique.page

And here's something I'd genuinely appreciate:

If you try Critique, don't just submit your own project. Take a moment to help another builder too.

That's how I want this community to grow.

I'd love to hear from other developers:

What's the most useless feedback you've ever received about a project you built?

And what kind of feedback do you actually wish people would give you?

I'm reading the replies.

AI Made Building Easier. Getting Your First 10 Users Is Still Hard.

Dinesh Bista — Sun, 01 Nov 2026 01:05:31 +0000

A few months ago, I started building a project called Critique.

The idea was simple: give developers and indie makers a place to share what they're building, ask one focused question, and get honest feedback from real people.

I thought building the product would be the biggest challenge.

I was wrong.
Building software is getting easier
AI tools have changed how developers work.

Today, you can:

Generate a frontend in minutes.
Build APIs with AI assistance.
Debug code faster.
Create prototypes without a large team. As a solo developer, I use these tools to move faster.

But there's a problem.

Building something doesn't mean people will use it.

You can have a working application, a clean interface, and a long list of features, but still struggle to find your first users.
The real challenge starts after building
When I started working on Critique, I realised that getting feedback was not as easy as I expected.

Posting a project on social media might get you a few likes.

Sharing it in a community might get you some comments.

But those things don't always tell you what you actually need to know:

Does someone understand what I'm building?
Would they use it?
What's confusing?
What should I improve first? I didn't want another place where people simply promote their projects.

I wanted to build something around meaningful feedback.
Why I built Critique
Critique is an open-source platform built around one simple workflow:

Share your project.
Ask one specific question.
Let real people explore it.
Collect feedback.
Use that feedback to improve. The goal isn't to collect as many opinions as possible.

It's to get useful perspectives that help you make better decisions.

You can explore it here:

Website: https://critique.page
GitHub: https://github.com/BistaDinesh03/critique What I'm learning as a solo founder Building Critique has taught me a few things.

More features don't automatically mean more value.

Sometimes one useful feature is better than ten features nobody asked for.

Getting users requires conversations.

You can't just publish a product and expect people to discover it. You need to talk to people, understand their problems, and listen.

Feedback is only useful when you act on it.

Collecting feedback is the beginning. Understanding it and deciding what to change is where the real work happens.

Open source is about people, not just code.

A contributor who reports a problem, improves documentation, or helps another user can make a meaningful difference.
What's next for Critique?
I'm still improving the platform, fixing issues, and learning from the people who use it.

I also want to make it easier for developers to discover interesting projects and give each other useful feedback.

I don't have everything figured out yet. That's part of building in public.
A question for other developers
If you're building a side project, startup, or open-source tool:

What's your biggest challenge right now?

Building the product?
Finding your first 10 users?
Getting honest feedback?
Turning feedback into improvements? I'd genuinely like to hear what you're experiencing.

I Got Tired of Building Projects Without Getting Useful Feedback. So I Built Something.

Dinesh Bista — Sat, 31 Oct 2026 02:25:09 +0000

An open-source project, a problem I experienced myself, and what I've learned trying to build a community around it.

You finish building a project.

You publish it. Maybe you share it on Reddit, X, or LinkedIn.

A few people visit. Some might even leave a star.

But then you wonder:

Did anyone actually understand what I built? What should I improve? Would anyone use it again?

I've experienced this more than once.

As an independent developer building projects in Japan, I realized that getting useful feedback can sometimes be harder than writing the code itself.

That's what led me to build Critique.
The idea behind Critique
[Insert an actual screenshot of the Critique homepage here]

I wanted to create a simple place where developers and makers could get feedback on their projects without having to chase people around different communities.

The concept is straightforward:

Share something you've built.
Ask one specific question.
Let other people give honest feedback. The focus isn't on collecting likes or followers. It's on getting perspectives that can help you make better decisions about your project.

You can try it here: critique.page.
Why open source?
I could have kept the project closed, but I chose a different direction.

I wanted other developers to be able to see how the platform works and participate in building it.

That means anyone can:

Explore the codebase.
Report bugs and open issues.
Suggest improvements.
Submit pull requests.
Help influence the project's direction. I also get to learn from people who approach problems differently than I do.

That's one of the things I enjoy most about open source.
What happened after making it public?
[Insert your actual GitHub repository screenshot here, showing stars, forks, issues and contributors]

The project has now reached:

2,000+ visitors
30+ contributors Seeing other developers open issues, review the code, submit pull requests, and contribute has made this journey much more interesting.

I'm not sharing these numbers as a success story. They're simply milestones along the way.

There are still bugs to fix, features to improve, and plenty of things I haven't figured out.
What I'm trying to learn next
The biggest challenge I'm thinking about now isn't necessarily adding more features.

It's getting people to participate.

How do you encourage someone to leave thoughtful feedback instead of just visiting a page?

How do you build a community where people genuinely want to help each other?

And how do you make a small open-source project useful enough that people keep coming back?

I'm still figuring these things out.
Come take a look
If you're building a side project, working on an open-source project, or just curious about what I'm making, I'd love to hear your thoughts.

Try Critique: https://critique.page

Explore the source code: https://github.com/BistaDinesh03/critique

You don't need to contribute code to participate. Trying the platform and sharing an honest opinion is already helpful.

And if you're an open-source contributor, you're welcome to join us.

Your friends say “Looks good!” But would anyone actually use your product?

Dinesh Bista — Sun, 18 Oct 2026 05:41:47 +0000

You spend weeks building your side project.

You finally show it to someone.

They say:

“Looks good!” 👀

But what does that actually tell you?

Is your product clear? Would they use it? What should you fix first?

You're still guessing.

That's the problem I'm trying to solve with Critique.

🔎 What is Critique?

It's a platform where you can:

Share your project.
Ask one focused question.
Get real feedback from people.
Figure out what to improve next.

No AI-generated feedback. Just human responses.

👉 Try it: https://critique.page

But here's what I really want to know:

If you're building a side project, what's harder?

A) Getting people to try it

B) Getting honest feedback

C) Knowing what to build next

Drop A, B, or C in the comments — and tell me why. I want to learn from other builders, too.

Your Users Aren't Giving You Bad Feedback. You're Asking the Wrong Question.

Dinesh Bista — Sun, 20 Sep 2026 03:28:41 +0000

You show someone your product.

They look at it and say:

“Looks good.”

You say thanks.

Then you go back to building with absolutely no idea what to change.

I started thinking the problem isn't always bad feedback.

Sometimes we're just asking for it badly.

Instead of:

“What do you think?”

Try:

“Is it immediately clear what this does?”

“Would you actually use this?”

“What would stop you from using it?”

The difference is simple:

A broad question gets an opinion.
A specific question gets an answer you can act on.

That's actually why I built Critique.

You share what you're building, ask one specific question, and get focused feedback from another builder.

Ask one question. Get real answers.

If you're building something, try it:
https://critique.page

And I'm curious:

What's the most useless feedback you've ever received on something you built?

I'll start:

“Looks good.”

“What do you think?” is probably the worst question to ask for feedback

Dinesh Bista — Fri, 28 Aug 2026 02:50:13 +0000

I’ve noticed something while building my own projects.

Whenever I showed someone something I built and asked:

“What do you think?”

I usually got:

“Looks good.”
“Nice project.”
“I like it.”

Nothing wrong with that, but it doesn't really tell me what to improve.

So I started asking a different kind of question.

Instead of:

“What do you think of my app?”

Try:

“Is it immediately clear what this app does?”

That gives someone something specific to look at — and gives you an answer you can actually do something with.

That’s the idea behind Critique, a platform I’m building for developers.

You share something you built, ask one question you genuinely want answered, and get feedback focused on that question.

I'm still building and testing it, so I'd really like some honest feedback from other developers.

What’s the best piece of feedback you’ve ever received on one of your projects?

If you want to try Critique with your own project:

https://critique-qqz9.onrender.com

[Boost]

Dinesh Bista — Sat, 22 Aug 2026 11:50:13 +0000

Dinesh Bista

Aug 21

I Built a Local-First Coding Activity Tracker for VS Code

#vscode #opensource #productivity #programming

4 min read

I Built a Local-First Coding Activity Tracker for VS Code

Dinesh Bista — Fri, 21 Aug 2026 09:01:56 +0000

How much time do you actually spend coding each day?

I wanted an easy way to answer that without sending my coding activity to another service, so I built DevPulse, a local-first coding activity tracker for VS Code.

It tracks coding time, projects, programming languages, Git activity, streaks, and more while keeping the data on your machine.

DevPulse currently has 21 users, and I'm now looking for developers who use VS Code to try it and tell me what I should improve.

What is DevPulse?

DevPulse is a coding activity tracker built directly for VS Code.

The idea is simple: while you code, DevPulse records your local activity and turns it into useful information about your coding habits and progress.

You can see:

Coding time
Coding streaks
Daily, weekly, and monthly goals
Project activity
Programming language statistics
Git activity
Weekly analytics
Coding activity over time
Monthly and yearly summaries
Shareable progress cards

If you want to try it, you can install DevPulse from the VS Code Marketplace.

See where your coding time goes

One of the main things I wanted to understand was where my coding time actually goes.

DevPulse breaks activity down by project, workspace, files, hours, and programming languages.

Instead of only seeing a total number of hours, you can look back and see which projects you actually spent that time working on.

Git activity and weekly analytics

Coding time is only part of the picture.

DevPulse also brings Git activity and weekly coding statistics together so you can see how your week went.

You can view commits, coding time, daily averages, best days, sessions, and other weekly statistics.

The goal isn't to turn coding into a competition or tell you that you need to code more.

It's simply a way to look back and understand your own work.

Understand your programming languages

If you work on different projects, you probably switch between languages more often than you realize.

DevPulse gives you an overview of the programming languages you use and how your coding activity changes over time.

This can be useful when you're learning a new technology, working across multiple projects, or simply curious about what you actually spend your time writing.

Why I built it

I wanted a coding tracker that worked directly inside VS Code and stayed out of the way.

I also wanted to keep my coding data private.

DevPulse does not require an account, does not use telemetry, and does not send your coding activity to a server. Your data is stored locally on your machine, and you can export it whenever you want.

The idea is simple:

Open VS Code, write code, and understand your progress.

A local-first alternative to cloud-based coding trackers

There are already several useful coding activity and developer productivity tools, including WakaTime.

I'm not trying to claim that DevPulse is better for everyone.

Instead, I'm exploring a different approach: a local-first coding tracker for VS Code where your activity stays on your own machine.

If privacy and local data are important to you, that's the main reason you might prefer DevPulse.

Share your coding progress

I also wanted DevPulse to make it easy to share progress without sharing your complete coding history.

You can create shareable summaries using different layouts and copy them for use elsewhere.

It's a small feature, but it makes it easier to share milestones, weekly progress, or coding statistics with other developers.

What I'm trying to learn

DevPulse is still evolving, and this is the part where I need feedback from other developers.

I'm currently trying to grow from 21 users to my first 100, but the number itself isn't the most important part.

I want to find out whether DevPulse is actually useful.

If you try it, I'd especially like to know:

What did you find most useful?
What felt confusing or unnecessary?
What feature would you want next?
Would you keep using it?

You don't need to write a detailed review. Even a short comment about something you liked, disliked, or found confusing can help.

Try DevPulse

If you use VS Code, I'd love for you to give DevPulse a try.

Install DevPulse from the VS Code Marketplace

DevPulse is open source, so you can also inspect the project, report issues, or suggest improvements on GitHub:

View DevPulse on GitHub

About the project

I'm a student developer in Japan, and DevPulse is one of the open-source projects I'm building while learning and working on problems I find interesting.

I decided to share it here because I want feedback from developers who actually use VS Code.

If you try DevPulse, tell me what you think.

What would you change?

What would make you keep using it?

Your feedback will help shape the next version.