Build: WhoStat — a daily sports stats guessing game
Time spent: A few hours
Tools used: Claude (chat), Claude Code, GitHub Pages, Cloudflare
The idea was simple: Wordle, but for sports nerds.
You get a stat line — career numbers, no name attached — and three guesses to figure out which player it belongs to. Get it wrong, you get a hint. Get it wrong again, bigger hint. Three sports, three daily puzzles: NFL, NBA, MLB. Come back tomorrow for new ones.
That’s WhoStat.
The interesting part isn’t the idea. There are a dozen sports guessing games out there. The interesting part is how I built it — because I used Claude twice. First as a thinking partner to plan the whole thing. Then as the builder to actually make it.
Phase One: Thinking Out Loud With Claude
Before I wrote a single line of code — before I opened Claude Code at all — I sat down in a regular Claude chat and just started talking through the project.
This is the part most people skip when they talk about building with AI. Everyone wants to show the finished product. Nobody talks about the conversation that got them there.
I started broad. Here’s what I want to build. A daily sports guessing game. Three sports. Stat-based clues. Wordle-style progression. Then I started asking Claude to help me make decisions. How should the hint system work? Should it be one puzzle that rotates sports, or three puzzles running at the same time? What stats actually make good clues versus ones that give it away immediately?
Claude helped me think through it the way a coworker would — except this coworker never gets tired of your side project and doesn’t change the subject to talk about their own thing.
By the end of that conversation, I had a clear architecture: three simultaneous daily puzzles with independent game states, a static site with no backend, player data bundled as JSON at build time, and a phased prompt plan I could hand directly to Claude Code.
That last part is the move. I didn’t just plan the app — I planned the prompts. Twelve of them, organized into five build phases: scaffolding and data, game logic, UI, social sharing and polish, and deployment. Each prompt was specific enough that Claude Code could execute it without me having to babysit every decision.
Regular Claude chat became the architect. Claude Code became the contractor. Same brain, different jobs.
Phase Two: Building It With Claude Code
The build itself used my usual stack: Claude Code writing the code, pushing to GitHub, deployed through Cloudflare Pages. Next.js with static export and Tailwind CSS. No database, no server, no API calls at runtime. Everything baked in at build time.
I fed Claude Code the prompts one at a time and let it work. Scaffolding went up clean. Game logic came together. The UI landed in a good spot without much fussing.
Then the problems started.
The Snags
The API wall. My original plan was to pull player data from real sports APIs — balldontlie.io for NBA, the MLB Stats API, and so on. Smart plan. One problem: Claude Code runs in a sandboxed environment, and those APIs aren’t reachable from inside it. The connection just dies.
So I pivoted. Instead of building a data pipeline that fetches from APIs, I had Claude Code generate curated static JSON datasets directly. Two hundred and fifty players per sport, all active from 2015 to present including recently retired guys. Career stats, accolades, difficulty ratings — all baked right into the build. No API dependency at all.
Honestly? The result is better. No rate limits. No API keys to manage. No risk of a third-party service going down and taking my game with it. Sometimes the workaround is the upgrade.
The team history problem. This one was sneakier. Players change teams. A lot. And the initial data wasn’t reflecting that — guys were showing up with only their current team, which makes the guessing game either too easy or misleading depending on who it is.
If you’re trying to guess a player from their career stats and the only team listed is where they finished, you’re missing half the puzzle. A quarterback’s career numbers look very different when you know they played for three franchises versus one. That context matters for the game to feel fair and fun.
Getting Claude Code to handle team histories properly — multiple teams, in order, with the right years — took some back and forth. Not a showstopper, but the kind of thing where you realize the data model you planned in phase one didn’t account for the messy reality of actual sports careers.
What WhoStat Actually Does
You go to whostat.com. You pick a sport — NFL, NBA, or MLB. You see a stat card with career numbers: touchdowns, yards, completions, whatever’s relevant to that sport. No name. No photo. Just numbers.
You get three guesses. Each wrong guess unlocks a new hint — maybe the player’s years active, maybe an accolade, maybe a team. By the third guess, you’ve got enough information that you should be able to narrow it down if you know your stuff.
Get it right and you can share your result. Come back tomorrow and there are three new puzzles waiting.
The player pool covers 250 players per sport, all from roughly the last decade, which keeps it current enough that casual fans have a shot but deep enough that the hard ones will stump people.
The Two-Claude Workflow
The real takeaway from this build isn’t WhoStat itself — it’s the process.
Using Claude chat to plan and Claude Code to build is a workflow that makes these projects dramatically faster. The planning conversation isn’t filler. It’s where you make the decisions that save you hours of debugging later. What’s the data model? How does state management work? What are the edge cases? You answer all of that before a single file gets created.
Then when you hand Claude Code a well-defined prompt, it actually executes. It’s not guessing what you want. It’s building what you already decided.
The whole thing — planning, building, debugging the API issue, fixing the team history problem, deploying — took a few hours. For a fully functional three-sport daily game with 750 players and a share feature.
I’m not saying every build will go this smoothly. But the two-step approach — think first, build second, with the same tool doing both — is the closest thing I’ve found to a repeatable system for shipping side projects fast.
And that’s kind of the whole point of Build and Bail.
Play it: whostat.com
Stack: Claude (chat) → Claude Code → Next.js → GitHub Pages → Cloudflare
Status: Live. Until I get bored.