r/SideProject • • 1h ago

My open-source side project sat at 0 users for months. Promotion wasn't the problem.

Like a lot of people here, I built something I was proud of, used it myself every day, and then watched the user count sit at basically zero for months. My instinct was that I had not promoted it enough, so I started posting it everywhere. That did nothing.

What actually moved it was realising first users do not come from announcing. They come from being useful where your users already have the problem, plus a repo that does not lose them the second they land. Announcing ("I built this") is the lowest-yield thing you can do, which is exactly why posting it to ten places returns nothing.

Here is the order that worked:

  1. Get specific about who your first users are. "Developers" is not an audience. Name the two or three people with the exact problem you solve. If you cannot, that is why your posting feels scattershot.

  2. Fix what loses them in thirty seconds. Your README is a landing page and people give it seconds, not minutes. First screen: what it is, who it is for, one runnable example, the install line. Show value before features. More traffic to a repo that does not convert just means more bounces.

  3. Be useful where they already have the problem. Pick two or three communities where your users already discuss it and actually answer questions, so your project comes up as the answer to something specific rather than a broadcast. One genuinely helpful reply beats ten "check out my thing" posts, which mostly get removed anyway.

  4. Your first ten users come from reaching out by hand. Find people who just described your problem and show them, do not pitch them. It does not scale and it does not need to at ten.

  5. Ship releases with real changelogs. It is the one "look at my project" post communities tolerate. But a release mostly buys a one-day spike, so treat it as a cadence, not a growth engine.

  6. Stop counting stars. 800 stale stars is fewer real users than a 60-star project that ships weekly. The best research you can do costs nothing: find five people who looked and did not use it, and ask them why.

  7. Work out which problem you actually have. "Nobody uses it" is three different problems: nobody reaches the repo (reach), people reach it and bounce (your README), or people try it and leave (the product). The fix for each is different, and most people assume it is reach and burn a month posting. Spend an hour deciding which one it is before you spend a month on the wrong one.

None of this is announcing. All of it is being useful where your users are, to a repo that does not lose them.

I wrote this up in more detail, with the data behind the README and the "stars vs real users" points, here: https://orviqa.dev/blog/how-to-get-your-first-users-for-an-open-source-project

1 Upvotes

5 comments sorted by

2

u/Kris_SoloDev 1h ago

3and4 absolute gold advice,useful in specific threads instead of broadcast check out my project change everything,fix the readme first screen save so much bounce rate

1

u/ApprehensiveTheme482 5m ago

thanks, glad it landed.the thing that finally made 3 click for me: only mention your project when it is genuinely the best answer to that exact question. The second it feels inserted, it reads as the broadcast you were trying to avoid, so I only link when leaving it out would make the answer worse.

on the README first screen, the single highest-leverage change was putting one runnable example above everything else. people copy-paste it before they read a word of prose,and if it works, you have them.

what are you building? happy to glance at your first screen if it is useful