Vault
research

Fantasy FAANGball: Can You Build a Fantasy Sports League for Software Engineers?

Created

Fantasy FAANGball: Can You Build a Fantasy Sports League for Software Engineers?

Related: execution-plan-phase-0-1-2 Informs: Projects/sigil, Projects/edge-llm Led-to: Projects/fantasy-hubball (MVP merged 2026-03-28)

The Idea

Inspired by KRAZAM's Fantasy FAANGball video — a satirical take where developers are drafted, traded, and evaluated like athletes — could you actually build this using real public data from GitHub (and maybe LinkedIn)?

The core mechanic: draft real developers, score them based on public activity, trash-talk your friends when their "star pickup" only merged 2 PRs in a sprint.

What Data Is Actually Available?

GitHub (the primary source — this works)

GitHub's GraphQL API and REST API expose substantial public activity data:

Data Point API Access Fantasy Relevance
Commits (public repos) contributionsCollection via GraphQL Base "yards" stat
Pull requests opened GraphQL + REST Offensive plays
PR reviews given GraphQL Defensive plays
Issues opened/closed GraphQL Assists
Stars received REST "Fan votes" / popularity
Repos created REST "New franchise" events
Languages used REST Position (Go = lineman, Python = quarterback, Rust = kicker)
Contribution streak GraphQL "Games started" / consistency
Followers REST Market cap
Organizations REST Team affiliation (actual FAANG or not)

Rate limits:

The GH Archive goldmine: GH Archive records all public GitHub events and makes them available via Google BigQuery. 1 TB/month free tier. This means you can run SQL queries like "who had the most merged PRs at Google repos last week" across the entire platform's history. This is your stats engine.

LinkedIn (basically unusable)

LinkedIn's API is locked down hard:

Verdict: LinkedIn is a dead end for automated data ingestion. You could allow users to manually link their LinkedIn for profile context, but you can't programmatically pull "Senior Engineer at Meta" for scoring purposes.

Workaround: GitHub org membership + repo contributions can infer company affiliation for open-source-active FAANG employees. Google, Meta, Microsoft, Amazon all have public GitHub orgs. This isn't comprehensive but it's legal and sufficient for the comedy.

What Already Exists?

The competitive landscape is thin, and nothing does the fantasy sports framing:

Product What It Does Fantasy Sports?
devActivity Gamified GitHub analytics (XP, levels, badges, leaderboards) No — individual gamification, not drafting/competing
GitRanks GitHub profile scorecard + leaderboards No — leaderboard only
committers.top Most active GitHub users by country/city No — static ranking
RankDevs VS Code tracking + GitHub/LeetCode integration No — personal portfolio
Commit Rank AI-based GitHub commit ranking No — ranking only
Gitstar Ranking Top 1000 by stars No — stars only

Nobody is doing the fantasy sports mechanic. Everyone is doing leaderboards. The draft → roster → weekly scoring → head-to-head → trash talk loop doesn't exist.

Blaseball: The Closest Analog

Blaseball (2020-2023) was a "fantasy fantasy sport" — absurdist baseball with simulated teams, cosmic horror events, and community governance. It got $3M seed funding and peaked at 30,000+ active participants.

Key lessons from Blaseball:

Fantasy FAANGball would share DNA with Blaseball: the comedy and social layer matters more than the accuracy of the stats. You're not building Bloomberg Terminal for GitHub — you're building a reason for engineers to trash-talk each other.

How Would It Work? (Mechanics Sketch)

Core Loop

Draft → Weekly Scoring → Head-to-Head → Trades → Trash Talk → Repeat

The Draft

Scoring

Weekly points calculated from GH Archive / GitHub API data:

Action Points Rationale
Commit to public repo 1 Base stat
PR opened 3 Shows initiative
PR merged 5 Delivery
PR review given 2 Team play
Issue opened 1 Engagement
Issue closed 2 Resolution
Star received (on their repo) 0.5 Popularity bonus
Repo created 3 Entrepreneurial
Contribution streak day 1 Consistency
Sev 1 caused (joke stat) -10 KRAZAM energy

The "Sev 1" would have to be simulated (random event, like Blaseball's incinerations) since outages aren't in public data. This is where the comedy lives.

Head-to-Head

Social Layer (This Is the Real Product)

AI-Generated Commentary (Where Your LLM Skills Apply)

This is where it gets interesting for you specifically. An LLM could:

Technical Feasibility

Data Pipeline

GH Archive (BigQuery)          GitHub GraphQL API
       ↓                              ↓
  Historical stats              Real-time updates
       ↓                              ↓
       └──────────┬───────────────────┘
                  ↓
          Scoring Engine
                  ↓
         Player Stats DB
                  ↓
    ┌─────────────┼─────────────────┐
    ↓             ↓                 ↓
 Matchups    Leaderboards    AI Commentary
    ↓             ↓                 ↓
    └─────────────┼─────────────────┘
                  ↓
           Web App (Next.js?)

Stack Options

Component Options
Data ingestion GH Archive via BigQuery + GitHub GraphQL API for real-time
Backend Node.js/TypeScript or Python
Database PostgreSQL (player stats, leagues, rosters)
Frontend Next.js (you already know this stack from Sigil)
AI commentary Claude API or local LLM for generated content
Auth GitHub OAuth (natural — users already have accounts)
Real-time WebSockets or SSE for live draft, score updates

What's Hard

  1. Consent / ethics — You're tracking real people's public activity and making a game of it. Even though it's public data, turning someone into a fantasy sports player without their consent has social risks. Mitigation: let people opt out, or require opted-in players only.

  2. Gaming the system — Once people know they're being scored, they'll spam commits. Scoring needs to weight quality signals (PR merges, reviews) over quantity (raw commits).

  3. Private repos — Most FAANG work happens in private repos. A "Meta Staff Engineer" might show zero GitHub activity because all their work is internal. This limits the player pool to open-source-active developers.

  4. Scoring balance — Making the points feel fair and fun requires iteration. Too granular = confusing. Too simple = boring.

  5. Scale — GH Archive queries on BigQuery could get expensive at scale. The free tier (1 TB/month) is fine for MVP but production usage needs cost management.

Business Viability

Who's the customer?

Revenue models

Model How Revenue Potential
Freemium Free leagues, paid premium features (custom scoring, AI commentary, private leagues) Low per-user, needs scale
B2B/Teams Sell to engineering orgs as a team engagement tool $5-20/user/month, more viable
Sponsorship Tech companies sponsor "seasons" (like fantasy football sponsors) Brand deals, moderate
Merch/Content KRAZAM-style content arm, merchandise Supplementary

Market size reality check

Fantasy sports in the US is a ~$30B market. But this is a niche within a niche — tech workers who do fantasy sports AND care about GitHub stats. That's maybe tens of thousands of people, not millions. This is a community product, not a venture-scale business.

Blaseball comparison: Got to 30K active users and raised $3M. That's the ceiling without going mainstream. Could be a fun project or a modest business, not a unicorn.

Why This Is Interesting For You Specifically

  1. It combines your LLM skills with a consumer product. The AI commentary layer is the differentiator — nobody else would build this with production-quality generated content.

  2. It's inherently viral. Fantasy sports spread through friend groups. Each league of 8 people is 8 potential advocates.

  3. It's fun. You said the Builder comes alive. This is a Builder project, not an Analyst project.

  4. It doesn't conflict with Sigil or the workshop. Different audience, different value prop, could run in parallel as a side project.

  5. Your stack is already right. Next.js, TypeScript, Claude API, GitHub OAuth — you've built all of these before.

  6. It could be the "novel shareable content" that drives visibility. A blog post about building this + the actual product = Phase 0 material.

Risks and Honest Assessment

Risk Severity Mitigation
Consent/ethics backlash Medium Opt-in only, or use GitHub usernames people voluntarily submit
Small market High Accept this is a community project, not a startup
KRAZAM IP concerns Low You're building a product inspired by a comedy bit, not copying their content
Time investment vs. existing plan High MELCHIOR would say: you already have three things on your plate
Private repo blind spot Medium Lean into the comedy — "this player's stats are classified"
BigQuery costs at scale Medium Optimize queries, cache aggressively, use free tier for MVP

The MELCHIOR Test

Being honest: this is idea #6 on a list where you haven't shipped ideas #1-3 yet. The execution plan says blog → Sigil → workshop. Adding this before those are moving is exactly the pattern the Operator flagged.

But — if this is the thing that makes you actually ship something publicly (because it's fun and you want to play it yourself), then the priority math changes. The best plan is the one you execute.

MVP scope if you did it:

That's a weekend hackathon to prototype. Ship it, play one season with friends, see if it's fun. If it is, then it's worth more time. If it's not, you learned in 2 days, not 2 months.

Sources