Six seasons of this. Six seasons of cross-referencing box scores at midnight on a Sunday, praying I don’t fat-finger someone’s receiving yards and start a controversy in the group chat.

The league rules aren’t complicated. They’re just specific enough that no fantasy platform supports them.

Here’s the format: you draft NFL playoff players. No bench. Just a starting lineup — QB, two RBs, two WRs, a TE, and a FLEX. Points are cumulative across the entire postseason. No head-to-head matchups. No weekly resets. Your guys score until they stop playing football.

When a player’s team gets eliminated, you get substitutions. Four of them. Total. For the whole playoffs. Use one because your receiver’s team lost in the wild card round, fine — but now you’ve only got three left. Use one voluntarily because you think you can upgrade at tight end? Bold move. Same cost.

There’s a pick deadline each round. PPR scoring with 2-point conversion math that requires subtracting out the receiving yards, rushing yards, and reception points that were already awarded — otherwise you’re double-counting. The kind of rules that make perfect sense when you’re explaining them over beers and make every fantasy app’s settings page completely useless.

So every January, I become a human spreadsheet. Collecting emails. Cross-referencing box scores. Copy-pasting stat lines into a Google Sheet and hoping I didn’t accidentally give someone else’s touchdown to the wrong guy.

This year I decided to stop doing that.

The Planning Conversation

Same workflow as WhoStat. Before I opened Claude Code, I sat in a regular Claude chat and talked through every rule, every edge case, every “wait, what happens when…” scenario.

Roster structure. Substitution logic. The scoring engine — which turned out to be the hardest part, because the 2-point conversion math has to actively undo the PPR and yardage points that were already awarded to avoid counting them twice. That’s not a setting you toggle. That’s custom logic that I’ve been doing in my head while staring at a spreadsheet at 11pm for six straight Januarys.

I walked through pick deadlines, the admin panel I’d need to enter scores, how the public standings page should work so people can stop texting me “what’s the score,” and what happens when someone burns all four subs by the divisional round.

Thirty minutes. Ten specific prompts covering project setup, data schema, the scoring engine, a query layer, public standings and team detail pages, an admin panel, business rule validation, API routes, and deployment.

Ten prompts. That’s the whole app that replaces six years of spreadsheet misery.

What It Actually Does Now

The site has a registration page where players pick their own seven-player roster and submit it themselves. No more emails. No more me manually typing “Josh Allen” into a cell at 1am because someone sent me their picks as a bulleted text message with no last names.

There’s a public leaderboard so everyone can check standings without texting the commissioner. A player results page showing how every drafted player is scoring across all rounds. An admin panel where I enter stats after each round — still manual, but now I’m entering them once into a real interface instead of hunting through a spreadsheet.

And the best part: a Hall of Champions page with every winner and runner-up since 2021. Gerard Balsamo sitting at two titles and three finals appearances like the dynasty he apparently is. The league’s history actually lives somewhere now instead of in scattered group chat memories.

Hosted on Railway. No database — just the app doing its thing. The commissioner still enters scores manually, but the site handles the math, the standings, the substitution tracking, and the public-facing everything.

The Build

Ten prompts, fed to Claude Code one at a time. The same approach that worked for WhoStat — architect in chat, execute in Code.

The scoring engine was the most satisfying part to watch come together. The 2-point conversion logic is genuinely tricky: you have to calculate the base PPR and yardage points, then figure out what portion came on 2-point plays, then subtract that out so you’re only crediting the conversion bonus. I’ve been doing this math manually for years. Watching Claude Code turn it into actual working logic felt like handing off a chore I didn’t realize I hated.

The registration flow was the other big win. People can go to the site, see the available players, pick their seven slots, and submit. No account needed. The commissioner (me) reviews and confirms. That single feature eliminates half the emails I used to get every January.

Why This One’s Different

Most of my builds are absurd on purpose. A pants delivery service. A URL lengthener. A calculator about children and tug of war.

This one replaces a real process that’s been annoying me every January since 2021. No more collecting picks from email. No more manually looking up every stat line on ESPN. No more copy-pasting numbers into a Google Sheet at midnight and hoping I didn’t give someone else’s touchdown to the wrong guy.

The league members get a real site with live standings and a place to register their own teams. I get an admin panel instead of a spreadsheet. Everyone wins — especially me, because I won the whole league in 2024 and now there’s a permanent record of it on the internet.

Will I maintain it forever? The playoffs only last a month. Build it once, use it every January, tweak it if the rules change. That’s not bailing — that’s seasonal engineering.

Build status: Live
Cost: Hosted on Railway
Users: The same 36 guys who’ve been arguing about playoff fantasy since 2021
Bail risk: Low — unless I somehow lose my own league, in which case the site might experience unexpected downtime

Read more at Build and Bail

This is the first Build and Bail project to complete the full cycle. Idea. Build. Ship. Bail.

WhoStat is a daily sports stats guessing game — Wordle but for sports nerds. You get a career stat line with no name attached and three guesses to figure out who the player is. Three puzzles a day: NFL, NBA, MLB. Wrong guesses unlock hints. New puzzles every day. 750 players in the database. The site runs itself.

I already wrote the full build log — how I used regular Claude chat to plan the whole project, turned that into twelve prompts, and fed them to Claude Code one at a time to build the thing in a few hours. You can read that here: WhoStat Build Log

This post is about the other half. The bail.

Why I’m Selling It

Because that’s the whole point.

WhoStat works. It’s a fun game. I play it myself sometimes. But I’m not the person who’s going to add leaderboards, streak tracking, push notifications, and an ad layer. I’m not going to maintain a player database across three sports for the next five years. I know who I am.

I built it to see if I could build it. I could. Now it’s someone else’s turn.

The Flippa Listing

I listed WhoStat on Flippa under Projects & Concepts — because that’s exactly what it is. A fully built digital asset with no revenue. Pre-monetization. The buyer gets the domain, the codebase, the 750-player database, and a deployment pipeline that costs nothing to run.

The honest pitch: this is a working product with a clear path to making money — ads, premium features, more sports — but zero financial history. You’re buying the build, not the business. Someone who wants a sports daily game without starting from scratch, this is their shortcut.

Check out the listing here: WhoStat on Flippa

The Takeaway

The Build and Bail philosophy isn’t about building things that fail. It’s about building things fast, being honest about whether you’re the right person to keep running them, and making room for the next idea.

WhoStat didn’t fail. I just finished my part.

If it sells, great — someone else gets a head start on something cool. If it doesn’t, the domain’s still mine, the game still works, and the build log still exists as proof that you can go from “I have an idea” to “it’s listed for sale” in less time than most people spend debating their tech stack.

Launch. Validate. Abandon. Repeat.

Play it: whostat.com

Buy it: WhoStat on Flippa

Build log: How I Built WhoStat

Status: For sale. The circle is complete.

Read more at Build and Bail

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.

Read more at Build and Bail