How GitShowcase Verifies Tool Reviews — Methodology v1.0

By 2026, the major SaaS review platforms had a structural problem they couldn't solve: AI-generated review spam. G2, Trustpilot, and Capterra all rely on email-verified accounts and after-the-fact moderation. Both can be defeated at scale — generate accounts, generate reviews, hope the moderators don't catch up.

GitShowcase's answer is identity at signup, not after the fact. You can't leave a review unless you sign in with GitHub and your account passes our checks. That gate doesn't eliminate fake reviews entirely — determined adversaries with old GitHub accounts and shipped code can still pose. But it raises the cost of fake reviews by 3-4 orders of magnitude vs email-only platforms. That cost shift is the moat.

When you click "Sign in with GitHub" we initiate standard OAuth 2.0 with the read:user scope. After authentication we pull the public profile and run four checks:

1. Account age. The GitHub account must be at least 90 days old. New accounts created specifically to leave reviews don't pass.
2. Public repository count. The account must have at least 3 public repositories with at least one commit in each. This filters accounts created for non-coding purposes.
3. Commit history. The account must show commits within the past 180 days. Inactive accounts can still review but their reviews carry lower weight.
4. Public organization membership. Accounts that are public members of organizations get a credibility bump because organizational affiliation is a signal that's expensive to fake.

The four signals combine into a reviewer credibility score from 0 to 100. Reviews from credibility < 30 are filtered. Reviews from 30-70 carry standard weight. Reviews from 70+ carry weighted-up influence on aggregate scores.

Each review combines three weights:

• Reviewer credibility (50% of weight) — the GitHub-derived score described above.
• Use-case match (30%) — does the reviewer's declared role and stack match the tool's typical buyer? A backend engineer reviewing a backend tool weights more than the same review of a frontend tool.
• Disclosure compliance (20%) — vendor employees must self-identify. Their reviews are flagged, weighted toward zero on their own product, and used only for comparative context.

Aggregate tool scores apply these weights then combine with recency decay (e^(-t/180days)) so a 2-year-old review weighs roughly half a 30-day-old review.

Three layers:

1. Sock-puppet detection. We run graph analysis on GitHub follow / star / contribution graphs. Accounts that share unusual structural patterns (mutual follows, identical commit timestamps, shared contribution targets) get flagged for human review.
2. Vendor employee detection. We cross-check reviewer GitHub orgs against the tool's GitHub org. If you work at Anthropic and review the Claude API without disclosure, we catch it. Reviews are filtered until disclosure is confirmed.
3. Dispute logs. Every removed or downweighted review leaves a tombstone — a placeholder in the review feed showing the dispute reason and timestamp. We never silently delete. Vendors can dispute via /contact/; the dispute log is public.

Tool aggregate scores update in real-time as reviews are submitted, weighted, and aged. Best-of rankings update quarterly with editorial review of the top-5 selection — the underlying score data updates continuously but we don't flip the ranking order between quarterly editorial passes (this prevents reviewer-cohort flapping from making the rankings noisy).

Comparison pages' "winner per row" determinations are rerun monthly. The TL;DR verdict is editorial-reviewed quarterly.

Email methodology@gitshowcase.com with the specific URL, the rule you believe was violated, and the evidence. We log every dispute publicly with timestamp and resolution. Most disputes resolve within 5 business days. The full dispute log is at /methodology/disputes/ (when first dispute is filed).

Methodology version: 1.0. Last updated April 30, 2026. Changes are versioned; previous versions remain accessible.