How I promoted my open source project and got 1K GitHub stars

I got 1,200+ ⭐️ on GitHub in 3 months — here's what worked

I’ve worked in tech for over a decade — from leading teams at major internet companies to co-founding a startup and raising funding. But earlier this year, I started something new: launching my first open-source project and trying to build a business around it.

On February 3, 2025, I pushed the first commit to Usertour, a developer-focused product tour builder. Three months later, it had over 1,200 GitHub stars.

This post isn’t a growth hack thread. It’s a reflection on what helped, what didn’t, and what I’d do differently next time — in case you're trying to grow an open-source project too.

Promotion isn’t optional — it’s necessary

A GitHub repo without visibility is effectively invisible. If you're building something for others to use, not promoting it is almost the same as not releasing it at all.

That said, visibility comes with a cost.

More stars means more users, and more users means more requests. You’ll get feature suggestions you didn’t plan for — maybe even ones that go against the original intent of your project. You’ll start to second-guess every breaking change, knowing someone out there might already be depending on it. At some point, your repo becomes a product, and you're no longer just coding for yourself.

But here’s the trade-off: visibility builds momentum. It gets your work in front of people who care. It opens doors. And if you’re trying to build a sustainable business, that attention isn’t just helpful — it’s essential.

Launch earlier than you think

If you wait until your project feels “done,” you’ve probably waited too long.

I announced Usertour when it barely had a working tour system and a few basic features. But the README was clear. The landing page had a demo. It solved a real problem — and that was enough to get attention.

The most important part of your early release isn’t the feature set. It’s whether someone landing on your page understands what it is, why it matters, and how to try it in 2 minutes or less.

GIFs, screenshots, short videos — anything that lowers the barrier to interest — are worth the effort. You’re not launching a product. You’re telling a story.

“Building in public” actually works

I used to be skeptical of the “build in public” trend — but it works, especially for dev tools.

From the start, I shared progress on Reddit, posted about milestones on Hacker News, and engaged with anyone who gave feedback. I didn’t have a huge audience. But every post helped me understand what resonated and what didn’t.

Reddit was surprisingly effective. Posts on /r/selfhosted and /r/webdev brought consistent traffic. Hacker News brought spikes — especially when I shared major updates or posted a “Show HN.”

Was there criticism? Of course. But most of it was useful, or at least thought-provoking. And once in a while, a stranger would jump in and defend the project more passionately than I ever could. That’s when you know you’re building something that matters.

Don’t just ship features — share the journey

After launch, the most common mistake is going silent.

You don’t need a huge release to post an update. A funny bug, a design choice you regret, a small feature you’re proud of — they all make for good stories. Keep sharing. Especially if you're a solo builder, this helps people feel like they’re on the journey with you.

When I launched v0.1.4, I wrote a short changelog post, added a demo video, and shared it with the same communities as before. That alone brought in another wave of stars and feedback.

What worked best wasn’t polished blog posts — it was honest, technical notes on what I was thinking and building.

Feature requests shape the roadmap — if you let them

Early adopters are a gift. They tell you what matters, what’s broken, and what’s confusing — often more directly than your own instincts.

After the first few weeks, I noticed patterns in GitHub issues: repeated asks, common pain points, broken expectations. Instead of trying to plan a roadmap in isolation, I started using those inputs to guide what I built next.

Not every suggestion makes sense. But recurring feedback is a strong signal. Listening carefully (without blindly agreeing) helped Usertour improve fast — and made contributors feel heard, which kept them coming back.

Final thought

There’s no secret formula. Growth is messy, inconsistent, and often luck-driven. But if you’re building something useful, and you’re willing to talk about it openly, people will find it.

Ship it. Share it. Learn fast. And don’t underestimate the compounding value of being just a little more visible each week.

---

These are the most important sources and strategies that helped me grow Usertour to 1,200+ stars on GitHub in just three months.

If you found this post helpful, I’d really appreciate it if you shared it with your dev friends!

• 🌟 GitHub: https://github.com/usertour/usertour

• 🌐 Website: https://usertour.io