BeforeVC
All articles
githubdue diligencefake stars

Fake GitHub Stars: How Angels Spot the 6M-Star Fraud

GitHub stars can be faked at scale. Here's how angel investors detect purchased traction versus the real thing in five minutes.

April 27, 2026 · 6 min read

Fake GitHub Stars: How Angels Spot the 6M-Star Fraud

A repo with 6 million GitHub stars is either the most important developer tool in the world, or someone paid for an audience. In 2026, it's often the second one.

Academic research has documented over 6 million fake GitHub stars spread across thousands of repositories, backed by organized networks of bot accounts manufactured specifically to inflate traction metrics. The services cost a few dollars per hundred stars, the accounts are convincing enough to fool a casual glance, and the founders using them know exactly which investors are watching star counts.

Here's how to run the check before it skews your due diligence.

Why This Matters for Angel Investors

Most angels treat GitHub stars the way they treat app store ratings: rough social proof that something is working. That instinct is mostly right. It breaks down at the edges, and the edges are where the fraud concentrates.

The relationship between GitHub stars and startup success is real. Organic star growth correlates with genuine developer interest, which correlates with adoption, which eventually correlates with revenue. But that chain only holds when the stars are authentic. Fake stars mimic the output without generating any of the underlying behavior. A repo with 200,000 purchased stars has zero retention, zero word-of-mouth, and zero conversion.

The problem is that founders know investors watch this number. So some of them buy it.

The Four Patterns That Give It Away

Bulk star purchases leave fingerprints. Once you know what they look like, a five-minute check catches most of them.

Vertical spikes with no external cause. Real star growth happens in bursts tied to identifiable events: a Hacker News thread, a ProductHunt launch, a viral blog post. Every spike has a story. If a repo gained 40,000 stars over a weekend and you can't find a single HN post, launch announcement, or influential tweet explaining it, that's the first flag. Star-history.com shows growth curves visually. Look for organic stairstepping, not vertical cliffs.

Blank stargazer accounts. GitHub's stargazer lists are public. Click through 30 random accounts on any repo that looks suspicious. Fake accounts all look the same: created recently, zero followers, zero contributions, no bio, nothing pinned. If 60-70% of the accounts you check were created within a month of a star spike, stop there.

A broken fork-to-star ratio. This is probably the fastest single check you can run. Real developer interest generates forks. Developers fork repos to experiment, to build on top of them, to file PRs. Buying forks is harder and more expensive than buying stars, so fraudsters skip it. The fork-to-star ratio is your quick sanity check. A repo with 500,000 stars and 800 forks is doing something wrong.

Issues and PRs filed by nobody. A genuinely popular repo attracts bug reports from strangers. It gets feature requests, questions, and contributions from people with their own commit histories. If a repo has 100,000 stars and 12 issues, all filed by the same two or three accounts, that's not a community. That's a ghost town with a painted front.

The Five-Minute Verification Workflow

Here's the actual process:

  1. Run the repo through star-history.com. Look at the shape of growth. Gradual accumulation with identifiable spikes is the real pattern. Vertical jumps followed by flatlines aren't.

  2. Sort stargazers by recently starred, click through 30 profiles. Track account age, follower count, contribution history. More than 25% blank accounts warrants a closer look.

  3. Check forks. Divide forks by stars. Under 5% deserves scrutiny. Under 1% on a repo claiming viral developer traction is close to a disqualifier.

  4. Search for the repo on Hacker News and Reddit. Every real star spike should have a traceable cause. If you can't find the launch post, the HN thread, or the community mention that triggered it, keep digging before you assume growth was organic.

  5. Cross-reference with package download stats where possible. If the project ships a Python package, check PyPI weekly installs. If it's a Node library, check npm. These numbers are much harder to fake at scale. A repo with 80,000 stars and 900 weekly PyPI downloads has a math problem.

If you're running this workflow across multiple repos per week, Bright Data ([BRIGHTDATA_AFFILIATE_LINK]) makes it easier to pull GitHub's public data programmatically rather than clicking through profiles one at a time.

What Genuine Growth Actually Looks Like

Organic star growth is lumpy. It comes in pulses tied to external events and then settles into a slower baseline. A repo that's genuinely useful gets rediscovered repeatedly: mentioned in a newsletter, referenced in a conference talk, included in an awesome-list, recommended in a Discord server.

The repos worth tracking are the ones where stars and forks both grow, where issues come from strangers with real commit histories, where the contributor graph is expanding. That's what the pattern from open-source to real adoption actually looks like. The community compounds or it doesn't. Fake stars stop at the vanity metric and nothing else follows.

Stars Are Still Useful - Just Not Alone

None of this means stars are worthless. They're still a legitimate part of any pre-revenue startup evaluation. The signal just needs verification before it informs a decision.

Two thousand genuine stars from identifiable developer accounts, growing steadily with forks and issues accumulating, tells you more than 200,000 anonymous stars and a flat fork count. Smaller real numbers beat larger fake ones every time.

Use stars as a filter that tells you which repos are worth investigating, not which ones have proven traction. The verification workflow is what converts a noisy metric into a useful one.

A strong developer tool startup shows up on GitHub AND on npm AND on HN AND in Discord AND in conference talks. That layered presence is expensive to fake. Single-metric inflation is cheap. If you're sourcing deals through GitHub due diligence, this cross-signal check is the difference between evaluating real momentum and buying a pitch.

The beforeVC weekly briefing runs exactly this kind of cross-signal analysis, flagging repos where multiple data points are moving together versus ones where only star counts are inflating. If you want to stay ahead of the noise and find genuine breakouts before they raise, it's worth adding to your weekly stack.

Some links are affiliate links. You will not pay more.

Get the signal before the noise

Each week we scan thousands of signals and surface the highest-momentum projects. Five emerging signals, ranked and scored. Read in under 2 minutes.

Free weekly briefing. No spam, unsubscribe anytime.