How to Get Your First 100 GitHub Stars

September 18, 2026 · 11 min read

A repository with 100 stars and a repository with 3 stars can contain identical code. Visitors treat them differently anyway. One looks adopted; the other looks abandoned. The difference has nothing to do with quality and everything to do with the threshold you have or haven't crossed.

The research on this is consistent. A widely cited study of 791 developers found that three out of four consider a project's star count before they use it or contribute to it. The same survey asked developers to rate popularity signals: stars came first, ahead of forks and watchers. Nobody is immune to this. You check the number too.

So the first 100 stars are not vanity. They are the credibility layer that makes everything after them easier. This guide covers what the published research actually says about getting there: readiness, launch timing, distribution, and the one shortcut that doesn't work. Before any of the tactics below, though, there's a step most launches skip - knowing what your repo looks like to a first-time visitor. You can run your repository through our free GitHub Launch Checklist and see the answer in about ten seconds.

Why are the first 100 stars the hardest?

Because early stars are social proof, and social proof requires other people to move first. That is the cold-start problem, and every repository starts inside it.

What makes it concrete: GitHub's star numbers follow one of four growth patterns - slow, moderate, fast, or viral - and most repositories sit in the slow bucket. The same research shows something useful for planning: repositories tend to receive stars fastest right after public release, then the rate stabilizes. There is no correlation between a repository's age and its star count. Old and forgotten is not a category that fixes itself; a repo that stalled in month two is usually still stalled in year two.

One more finding worth internalizing: stars are closer to public bookmarks than votes of confidence. Many people star something they intend to look at later and never open it again. That sounds cynical, but it is actually good news for you - it means the bar for the first star is lower than you think. It only feels high because nobody knows your repository exists yet.

What do you need before you ask anyone for a star?

A visitor decides in seconds whether a repository is worth a star. The ten things they judge are mechanical, fixable, and free: name, description, topics, README, license, demo link, installation instructions, contributing guide, issue templates, and the social preview image.

Run the checklist on your own repository and the output looks like this:

GitHub Launch Readiness
────────────────────────

Repository name      ✓ descriptive and searchable
Description          ✓ present and well sized
Topics               ⚠ 3/5 recommended
README               ✓ 743 words
License              ✓ MIT
Demo                 ✗ Missing - set a homepage, demo or docs link
Installation         ✓ installation or quick start found
Contributing guide   ✗ missing - add CONTRIBUTING.md
Issue templates      ✓ templates present
Social preview       ⚠ check manually in repo Settings

Launch readiness: 6.5/10

Fix the fails before you launch. A missing description or an empty Topics field is the difference between appearing in search results and not existing. A missing demo link means a visitor has to trust you blind. None of it takes more than an afternoon, and all of it is permanent.

Does launch timing actually matter?

Yes - measurably. A 2025 study tracked 138 repository launches on Hacker News from 2024 to 2025 and measured what happened to their star counts. The average launch gained 121 stars within 24 hours, 189 within 48 hours, and 289 within a week.

The same study found timing to be one of the strongest predictors of how a launch goes. Repositories posted between 12:00 and 17:00 UTC gained roughly 200 more stars than those posted at poor times - that window catches US morning and European afternoon traffic at once. The three factors that dominated predictions were the post's score, the repository's existing stars, and the posting hour. Together they explained about half the variance in week-long growth.

One result surprised me. The "Show HN" tag, which many developers treat as essential, showed no statistically significant advantage after controlling for other factors. The researchers suggest selection bias explains it: Show HN skews toward early solo experiments, while regular submissions feature more established projects. The tag is not the lever - the content of the post is.

Metric	What the study found
Stars after 24 hours	+121 on average
Stars after 48 hours	+189 on average
Stars after 7 days	+289 on average
Best posting window	12:00-17:00 UTC
"Show HN" tag	No significant advantage (p = 0.39)

These are averages, not promises. The distribution has a long tail - a few launches go viral and drag the mean up. Benchmark your own results against the median, not the headline number.

Where should you launch?

Anywhere developers in your niche actually spend time. The mistake is doing one post on one platform and calling it a launch.

• Hacker News. The highest-variance option. Weekday mornings in the 12:00-17:00 UTC window are the practical sweet spot; you also need to be present in the thread for the first two hours, answering objections. A launch you don't participate in is a post you wasted.
• Reddit. The right subreddit matters more than the size - r/opensource, language-specific subs, and niche communities where your tool solves a real problem. Read the rules first; drive-by promotion gets removed.
• dev.to and Hashnode. Write the story of building it. These posts index well and keep bringing traffic long after launch day.
• Lobsters. Smaller, technical, invitation-friendly. Good fit for infrastructure and tooling projects.
• Product Hunt and newsletters. Better for consumer-facing tools, but the early-morning timing works the same way.

Pick three to five places and do them properly rather than ten places badly. Plan the sequence: the launch post first, then same-day cross-posts, then a follow-up a week later with what you learned from the feedback.

What makes a launch survive past week one?

Shipping. The research shows that releases and active development accelerate star growth - repositories gain stars faster after releases, and growth flattens when projects go quiet. Your launch buys attention; your activity converts that attention into sustained growth.

The practical version: reply to every issue and PR in the first month. Ship a release within two weeks of launch. Post a short follow-up about what changed based on feedback. A repository that visibly responds to its users reads as alive, and that is what turns a one-week spike into the steady curve that compounds into trending eligibility.

There is a version of success that is actually a trap: the spike without the follow-through. A repo that gains 400 stars in a week and then sits untouched for six months looks worse than a repo that gained 100 and kept shipping. Visitors check the commit history. The second repo wins.

What about buying stars?

Short version: the research is not kind to it. A 2024-2025 measurement study analyzed roughly six million suspected fake stars across more than 15,000 repositories. Two findings matter here. First, fake stars gave a promotion benefit only in the short term - under two months - and became a burden after that. Second, the campaigns leave detectable patterns: newly registered accounts and stars arriving in tight synchronized windows.

That second finding is the one people miss. It is not the number of stars that gets a repository flagged; it is the shape of the growth. A spike from accounts with no history is a signature, and GitHub's own research has been documented flagging exactly that pattern for years.

What does work, if you decide you want early momentum: real accounts with genuine history, delivery spread over days rather than minutes, and signals - stars, forks, watches - growing together instead of one number jumping alone. That is what legitimate early momentum looks like, and it is the only version worth paying for. No method makes stars permanent; anyone promising that is selling you something they cannot deliver.

A first-100 checklist

The whole strategy in one list:

1. Run the readiness check. Fix every fail before anyone sees the repository.
2. Name it like a search query. The phrase people would type to find it, with hyphens.
3. Write the description for humans. One line, value first, keywords naturally included.
4. Set five to ten topics. They are free discovery surface.
5. Make the README answer three questions: what it does, who it is for, how to install it.
6. Plan the launch for a weekday, 12:00-17:00 UTC, and clear two hours to be present.
7. Post to three to five places on launch day, not ten.
8. Ship a release within two weeks. Momentum compounds; silence decays.
9. Track the curve, not the number. A steady slope beats a spike every time.

The first 100 stars are the hardest and the most valuable 100 a repository will ever receive. Everything past them is compounding. Everything before them is preparation - and preparation is the part you fully control.

FAQ

How many stars is good for a repo?

It depends on the ecosystem, but 100 is the first threshold that changes how people read a repository. Below 100, visitors wonder whether anyone uses it. Past 100, the question shifts to whether it fits their needs. 1,000+ is a strong signal in most categories, and top tools in crowded fields have five figures.

How long does it take to get GitHub stars?

There is no standard timeline. Most repositories grow slowly - a few stars a week - while a successful launch can add 121 stars in 24 hours and 289 within a week, according to a 2025 study of 138 Hacker News launches. The realistic plan is to be ready before the launch and to keep shipping after it.

Do GitHub stars actually matter?

Yes, as a discovery and trust signal - not as proof of code quality. In a widely cited 2018 study, three out of four developers said they consider star count before using or contributing to a project. Stars are closer to public bookmarks used as a tiebreaker than to votes of confidence.

Is it safe to buy GitHub stars?

No method makes stars permanent, and research on fake stars found that bought spikes promote a repository for less than two months before becoming a liability. What survives is momentum from real accounts with genuine history, delivered gradually. If you consider paid growth, that is the only version worth buying.

What should I do first?

Run your repository through the free GitHub Launch Checklist. It scores the ten things visitors judge - name, description, topics, README, license, demo, installation, contributing guide, issue templates and social preview - so you can fix the obvious problems before you ask anyone for a star.