GitVerdict

Inspiration

Every hackathon I've attended, I noticed the same pattern: participants with polished GitHub profiles — packed with starred repos, long commit histories, and clean READMEs — were getting shortlisted, while genuinely skilled developers got overlooked. But when you looked closer, many of those "impressive" profiles were full of red flags: code dumped in a single commit, burst commits the night before a deadline, forked repos with zero changes, and READMEs copy-pasted from tutorials.

I wanted to build a tool that reads between the lines — one that judges GitHub profiles the way an experienced senior developer would, not just by counting stars.

What it does

GitVerdict is a rule-based GitHub Audit Engine. Enter any public GitHub username, and it runs 7 independent analyzers against the profile:

Originality Index — fork ratio of genuine original work vs. untouched copies
Commit Timeline — detects rush burst commits crammed before submission deadlines
Commit Quality — audits message discipline (flags generic "fix", "update", "done" messages)
README Authenticity — detects copy-pasted boilerplate documentation across repos
Code Dump Detection — spots repos uploaded in a single session instead of built incrementally
Collaboration Signals — scans for external PR contributions, testing references, and community engagement
Account Maturity — flags brand-new accounts with suspiciously high repo velocity

Every signal generates an explainable, weighted score (A+ to F), a dynamic summary referencing the profile's exact strengths and weaknesses, and actionable improvement tips — so developers know exactly what to fix.

How I built it

The architecture is intentionally stateless and rule-based with no ML black box:

Backend — Node.js + Express REST API. Each of the 7 analyzers is a standalone module that receives raw GitHub API data and returns a score, label, verdict, and details object. A weighted composite score (originality and code dumps weighted 2x, others 1x–1.5x) produces the overall grade. The GitHub REST API is used for profile data, repositories, commits, events, and README content.

Frontend — React + Vite with vanilla CSS. The UI renders a full audit dashboard with tabbed breakdowns, an animated score counter, a 4-card quick metrics grid, repository filtering by flag type, collapsible improvement tips per metric, shareable links, and a README badge generator.

Key engineering decisions:

Commit quality analyzer excludes repos with < 3 commits and ignores first commits (initial commits are standard convention, not a red flag)
Code dump detection uses 4 heuristics including a compressed time-span detector — catches repos where large codebases are pushed across < 6 hours regardless of commit count
Collaboration scoring starts at base 15 (not inflated) so developers with no community signals can't score above 45 on that metric
Percentile ranking is seeded with a realistic bell-curve distribution so the first user always gets a meaningful rank

Challenges

The hardest problem was calibrating scoring thresholds to be accurate rather than generous. Early versions inflated collaboration scores (base of 40/100 for just existing) and flagged genuine commit messages like "add login feature" as generic because they contained the word "add". Every rule required real profile data to test edge cases.

The second challenge was compressed time dump detection — a repo with 8 commits and 53MB uploaded in 78 minutes is obviously a dump, but commit count alone wouldn't catch it. Adding a temporal span analysis (first to last commit date) solved this precisely.

What I learned

Rule-based systems with clear, explainable logic outperform black-box ML models when the domain is well-defined and interpretability matters
GitHub's REST API has a 60 req/hr unauthenticated limit — authenticated tokens are critical for production use
Scoring systems need ground-truth calibration against real profiles, not just intuition about thresholds