Star Forensic

For developer-tools investors

The VC's Guide to Spotting Fake Traction on GitHub: A Star Authenticity Playbook

Open the pitch deck of almost any developer-tools startup in 2026 and you will find a GitHub star count. It sits next to ARR and DAU as a traction metric, and it is treated with the same seriousness. But unlike ARR, GitHub stars have no audit trail, no invoice, no bank transfer to verify. A CMU paper presented at ICSE 2026 identified roughly six million suspected fake stars across about 18,600 repositories. If you are writing checks based on star counts, you are writing checks based on a number that an adversarial market has already learned to manufacture.

Why stars became a traction metric in the first place

Stars started out as bookmarks. A developer would find something interesting, tap the icon, and come back to it later. That was the entire feature. Over the 2010s the number migrated outward: it appeared on README badges, landing pages, awesome-lists, Hacker News threads, and eventually in the “traction” slide of seed decks. By 2020 it was routine to see a Series A memo that cited star count in the first three bullets, next to waitlist size and design-partner logos.

At that time the signal was defensible. Star manipulation existed, but the economics were awkward. Account creation was cheap, yet you could still sanity-check the graph by eye: a real launch on Hacker News had a recognizable shape, and a quiet repo that suddenly jumped 20,000 stars in a weekend looked wrong to anyone who cared to look. The Hacker News discussion on large-scale suspicious starring from the past year captures the shift: investors and practitioners now openly describe stars as a sourcing input, and that attention has created a market for manufactured stars that did not meaningfully exist five years ago.

The uncomfortable reality in 2026 is that the metric is old, the market around it is new, and the due-diligence habits of most funds have not caught up. If you are still using star count as a sourcing trigger without a second-derivative check, you are using a 2018 signal against a 2026 adversary.

What the fake star economy actually looks like

The supply chain is not exotic. It operates in three roughly visible layers.

Retail: Telegram and Discord groups. Individual sellers advertise stars at $0.10 to $0.50 each. The accounts are typically freshly created or purchased in small lots. Delivery is often within hours. These are the least sophisticated operators and also the easiest to detect after the fact, because account ages cluster hard against the delivery window.

Mid-tier: Fiverr, SEO resellers, and “growth” services. Packages in the $50 to $500 per 1,000 stars range. The language is polished — “organic GitHub promotion,” “developer marketing,” “community acceleration” — but the underlying fulfillment is usually an account pool, not real discovery. These vendors tend to pace delivery over days or weeks to make the curve look less obvious.

Industrial: organized farms. Account pools in the tens of thousands, with deliberate warming schedules: accounts open, star a few popular real projects, maybe follow a handful of well-known maintainers, then sit idle until they are directed at a paying target. This is the layer a serious check must be designed to catch, because the obvious tells — empty profiles, same-week creation dates, zero repos — have been partially engineered away.

The CMU ICSE 2026 paper quantifies the aggregate footprint. Key numbers worth memorizing before your next developer-tools deep dive:

Those are paper-reported estimates, not legal findings, and the authors are appropriately careful about false-positive risk. But the order of magnitude is what matters for investors: this is not a handful of bad actors, it is an industry with SKUs and pricing.

Three signals that don't require a data team

You do not need to build anything to use what follows. All three signals are computable from public GitHub data in under ten minutes. The point is not certainty — it is raising the cost of fooling you above the price of the stars themselves.

Signal 1: New-account concentration

Definition: the share of stargazers whose GitHub account was created within 30 days of the star event.

Organic baseline: mature, well-known repositories like microsoft/vscode, facebook/react, and rust-lang/rust typically sit in the 2.5% to 7.5% range. There is always some new-account traffic — real developers sign up for GitHub every day — but the share is bounded.

Suspicious threshold: sustained readings above 15% warrant a second look, especially if the repository is not a beginner-facing tutorial or a viral educational resource. As a directional data point, the FreeDomain repository discussed in the CMU work showed new-account concentration near 36% — roughly an order of magnitude above a healthy baseline.

Why this signal is structural. The economics of a bot farm push operators toward fresh or lightly aged accounts. An account that has survived GitHub's trust and safety filters for two years is expensive; an account spun up last week is near-free. When the marginal star costs a few cents, the marginal account has to be cheap too. That is why this ratio is hard to hide entirely — you can sprinkle a few aged accounts into the mix, but not all of them, or the unit economics break.

Signal 2: Zero-activity clustering

Definition: the share of stargazers with zero followers and zero public repositories at the time they starred.

Organic baseline: mature developer-tools repos sit in the 1.5% to 6.5% range. Some real developers are lurkers; some have private-only activity. The floor is never zero.

Suspicious threshold: readings above 10% deserve scrutiny, and readings above 20% are very difficult to reconcile with an organic community unless there is a clear external explanation (a large bootcamp cohort, a classroom assignment, a regional community that uses GitHub mostly as a bookmarking service).

Caveat worth stating out loud. This is the noisiest of the three signals. Plenty of real people make a GitHub account, star one thing, and walk away for a year. Interpreted alone, zero-activity clustering is a weak witness. Interpreted together with Signal 1, it becomes harder to explain away: an account that is both very new and has zero footprint at star time is a very specific profile, and seeing it over-represented is meaningful.

Signal 3: Fork-to-star ratio

Definition: total forks divided by total stars.

Organic baseline: healthy developer-tools repositories tend to cluster around ~0.16. Libraries and frameworks with active contributor communities often run higher; end-user applications run lower. The specific number varies by category, but the distribution is tight enough to be useful.

Suspicious threshold: ratios below 0.05 on projects claiming meaningful developer adoption are hard to justify. They mean a repo has been starred tens of thousands of times by people who never once pressed “fork” — the single action that implies intent to actually use or modify the code.

Why this is the strongest single indicator. Forks are expensive to fake in the way that matters. A star is one click; a credible fork means the account has to exist, the click has to register, and — if anyone bothers to look — the fork has to not be instantly empty and abandoned. More importantly, the economic ratio runs the other way: farms sell stars because stars are what pitch decks cite. Nobody pays to inflate forks, so they get left behind. When the ratio collapses, it usually means the star side of the equation has been pushed up by something the fork side was not part of.

You can compute this in one API call. Using the GitHub REST API:

curl -s https://api.github.com/repos/OWNER/REPO \
  | jq '.forks_count / .stargazers_count'

Run that on three or four unimpeachable comps in the same category before you run it on the target. You will calibrate a useful mental baseline in about three minutes.

A 10-minute due diligence checklist

You are not trying to prove fraud. You are trying to decide whether the traction number in the deck survives contact with public data. Walk through this before your next follow-up call.

None of these steps requires a data team. All of them together take less time than one partner meeting.

False positives to watch for

The same patterns that catch manipulation can also catch legitimate, explainable behavior. Before you challenge a founder, check the following.

Educational content and viral launches. A repo published by an influential educator — a Fireship video, a ThePrimeagen stream, a featured newsletter — can pull thousands of first-time GitHub users in a single day. Those accounts will be new, often empty, and will cluster hard in time. This looks statistically identical to a small bot-farm delivery. The tell is the external event: if there is a well-known video, thread, or newsletter dated within 48 hours of the spike, the pattern has an explanation.

Regional communities. Developers in parts of Asia, in particular, frequently use GitHub as a bookmarking and learning surface rather than a place to host their own code. The result is a legitimate user population with higher zero-activity rates than North American or Western European baselines. If your heuristics are tuned only on facebook/react-style comps, you will over-flag these communities for cultural rather than adversarial reasons.

Influencer mentions. A single tweet from a developer with a large following can produce a multi-thousand-star spike in a day. The stargazer profile of that spike will skew toward the influencer's own audience rather than the project's natural community, and it will look unusual compared to the repo's history. That is real, not fake.

The working rule is: never escalate on a single signal. Escalate when two or three signals point the same way and you cannot find an external event that explains the shape.

What to do when the signals look suspicious

The goal of this work is to make a better investment decision, not to publicly brand a founder as fraudulent. The signals above are probabilistic, and the cost of being wrong in public — to the founder, to your fund's reputation, to the broader developer community — is high. Treat the outcome as a conversation, not a verdict.

Do not accuse publicly. Even when the signals look bad, you are holding a set of indicators, not proof. Public accusations age badly when a legitimate explanation surfaces a week later.

Ask the founder directly, framed as curiosity. Something like: “We ran the repo through some standard checks and the new-account concentration came in unusually high — about 28%. Was there a specific launch or campaign that drove that? We want to make sure we understand the traction before we talk about a term sheet.” A real explanation will arrive in seconds. A fabricated one will be detectable by cross-referencing the dates the founder cites.

Ask for alternative validation. Stars are one surface; there are others. Request npm or PyPI download trends, Docker pull counts, Sentry or PostHog usage data for any hosted offering, read-only access to the commit history if the repo is private, or a brief written reference from a real user the fund can contact. Any one of these, produced willingly, is worth more than the star count itself.

Decide whether you are pricing in uncertainty or walking. For a pre-seed check, elevated star-manipulation signals might reprice the round but not kill it — especially if the product itself is strong and the founder gives a clean explanation. For a later round where the traction thesis is the entire investment case, the same signal should be much closer to a hard stop.

Closing: stars are one input, not ground truth

The point of this playbook is not to turn every partner meeting into a forensic exercise. Most repos are fine. Most founders are honest. The point is to make sure the number in the deck is doing the work you think it is doing — that it reflects developer attention, not a $300 invoice to a vendor on Fiverr.

If the three signals above ever become part of a routine investor check, the unit economics of the fake-star industry start to break. An adversary that has to fake new-account ratios, activity profiles, and forks simultaneously is paying a very different price than one that only has to deliver raw stars. That is the practical goal: not to eliminate manipulation, but to raise its cost above what it is worth.

If you want to see all three signals computed against a specific repository, with baselines and the underlying sample exposed, our methodology is public on this site — see the methodology page for formulas and limitations, and the homepage to run a check on any public repo. Treat the output the same way you would treat any other single data source: as one input, never as ground truth.