The Impulse Buy

I ordered the Gemmy / Haunted Living Hologram Crystal Ball from Lowes.com for $80 (item #7950690) and it showed up the next day. The stock videos were cool but I was excited to upload my own stuff. I installed the app (Google Play only for now, which feels good when most apps are iPhone first), connected to the devices local wifi network, and uploaded my first video (my daughter doing The Undertaker eye-roll so you only see the whites). It looked awesome.

Next, I uploaded a video of Madame Leota that I had downloaded from YouTube, but I quickly hit an issue.

Why my videos wouldn’t upload

When you upload a video in the app, the first step is where you set the crop. The display is circular and the app allows you to set what part of the video shows in the globe. This part worked fine, but when it would start the transfer, it would just reset the screen with no error message.

I tried the normal stuff. Compressing the video, trying different source videos, but nothing would work. So I went back to that original social post and found the source video they used. Theirs was 58 seconds, while mine was just over a minute.

Once I reduced the video length, everything worked. I can’t say this is the definitive root cause but it certainly seems to be.

Then I made my own videos

The Madame Leota video looks great, but I wanted more. So I hopped over to Gemini and started creating 10 second videos to upload to the device. Some looked great, some were just ok, but it was still a fun process.

Here are a few I made, in case you want to use them yourself.

You can view the full playlist here: https://www.youtube.com/watch?v=GPme6qe-ZRs&list=PLP2gEaE14RoQ

What I’d do differently

There’s not much I’d do differently. I would definitely reduce video lengths as mush as possible. And when using Gemini to make new videos, I’d be sure to prompt for the circle, not for a rectangle.

Otherwise, I’m just enjoying this decoration and prepping for the rest of my Halloween setup.

Read more at Build and Bail

I’m not doing that anymore.

I found a tool called VocalLab.ai on AppSumo, and once I opened the audiobook mode I realized I wasn’t looking at a voice cloning problem. I was looking at a casting problem I could actually afford.

Heads up: the AppSumo link in this post is a referral link. If you buy through it I get a cut. I bought it with my own money before I had any reason to write about it.

What changed

The old plan:

• Record all 9 episodes myself in Audacity
• Clone my voice in ElevenLabs for the counterpart character
• A 43-year-old man doing a 10-year-old’s voice for 2.7 hours

The new plan:

• Every character gets its own voice
• I write, direct, and edit — I don’t perform
• Audacity is now for assembly and timing, not recording

The honest version: I did test recordings. I sound like a 43-year-old man doing a 10-year-old’s voice. Finn Caspian works because that guy can actually do it. I can’t.

How VocalLab’s audiobook mode actually works

This isn’t the standard text-to-speech box. It’s structured for multi-character work:

• One character block at a time
• 2,000 character limit per block
• Inline sound tags dropped right into the text — [laugh], [breathe], [sigh]
• No steering prompts. The text and the tags are your only direction.

That last one matters. If you’ve used TTS tools where you write a separate “read this sadly, slower, more distant” instruction, that doesn’t exist here. Your only lever is the writing itself. Short sentences read slower. Paragraph breaks create air. Punctuation is direction.

Which means the script stopped being a script and became a set of instructions for a machine.

The two things I got wrong first

The pause problem. There’s a moment where Mike says “No. Way.” It has to land as two beats with a real gap. Generated as one block, it comes out as one flat phrase. The fix is three separate blocks — “No.” then silence I insert manually at about 0.8 seconds, then “Way.” Any dramatic beat in your script is a separate generation. Plan for it.

The bleed problem. Grandpa’s laugh was tagged inline at the end of his line and it smeared into the next thing he said. Standalone laughs get their own block with nothing in it but [laugh]. Generate alone, drop into the timeline manually.

The rewrite I didn’t see coming

The book is third person. “Mike opened one eye.” Standard middle grade.

But the podcast has a framing device — a Counterpart Log that opens and closes each episode in Mike’s voice — and that log was already first person. So I had a narrator saying “there’s a journal on my nightstand” and then, thirty seconds later, “Mike chewed his toast.”

It’s a small thing on the page. In audio it’s a guy talking about himself in the third person for 18 minutes.

I went back and forth with Claude on it. Third person is a legitimate audio drama convention — the narrator as an older Mike looking back. Finn Caspian does exactly that. But the log already set the precedent, and first person closes the gap.

Converted all of Episode 1. Mostly a find-and-replace with verb tense cleanup, not a rewrite. Two things I learned doing it:

• Description blocks stay mixed. “Olivia came stomping in,” not “she came stomping in.” Mike is still observing the scene, and first-person narration does this naturally.
• The end-of-episode teaser got better. “I learn the rules” beats “Mike learns the rules.” More personal, more hook.

Where it stands

• Episode 1 is formatted, converted, and partially generated
• Episodes 2 through 9 are scripted but not yet reformatted for the block structure
• Still recording all 9 before publishing any of them
• Still dropping 3 on launch day, weekly after that

Here’s the opening of Episode 1. Judge it yourself.

The stack, updated

• VocalLab.ai — all character voices (referral link — I get a cut if you buy)
• Claude — market research, adaptation, scripts, the first-person conversion
• Audacity — assembly, timing, manual gaps
• Buzzsprout — hosting and distribution
• Gemini (Lyria 3) — the music sting

Gone from the last version: ElevenLabs, and me.

The part I’m still uneasy about

I’m making a children’s podcast where no child ever hears a human voice.

I don’t have a clean answer for that. The alternative was a book nobody could find on KDP, or nine episodes of me doing a voice I can’t do. Bad audio doesn’t serve kids either. But I’m not going to pretend this is a neutral tradeoff, and I’m not going to hide it in the credits.

Tell me I’m wrong in the comments. I’ll read them.

Recording continues. Unless I bail.

Read more at Build and Bail

I needed a way to test a short-form video idea for my demotivational speaker alter-ego, Desmond Vance, without sitting in front of a camera every time I had a thought.

The plan was simple:

• Train a custom avatar in Gemini that matches Desmond’s look and voice.
• Generate short 10-second clips on demand.
• Drop the MP4s into Canva to add text overlays.
• Slap a badge over the Gemini watermark in the corner.

I wanted a zero-friction pipeline. I wanted to go from an idea in my head to a published TikTok in five minutes flat.

The Toolkit

• Gemini (Custom Avatars): Clones the look and voice from a source calibration video and generates new 10-second clips.
• Canva: Handles the vertical 9:16 layout, text formatting, and graphic overlays.
• TikTok: The destination for publishing and watching the numbers.

Here is how we set up the assembly line:

The Strategy / The Build

• Training the custom avatar
  • I dressed up as Desmond Vance:
    • Cheap wig
    • Reading glasses
    • Ugly tie
    • Dress shirt and suit jacket
  • I ran through Gemini’s avatar creation process.
  • I recorded the setup video directly in the tool, moving my head side to side and reading out the prompt numbers on screen so it could lock down my facial geometry and voice tone.
• Generating the clips
  • Once the avatar was ready, Gemini had Desmond’s look and voice saved.
  • I started generating 10-second clips by giving it simple visual actions:
    • Staring blankly at a desk
    • Looking unimpressed in an office
    • Walking through an empty hallway
• Polishing in Canva
  • I downloaded the raw 10-second MP4 and dropped it into a blank 9:16 vertical Canva canvas.
  • I set the video as the background.
  • I created a circular headshot badge and positioned it in the bottom corner right over the Gemini watermark.
  • I added bold, centered text across the top with Desmond’s quotes (“Master the Minimum,” “Lower Your Expectations”).

The Roadblocks

• Viewer distraction from the watermark
  • Big tool watermarks in the corner pull eyes away from the clip. I’m not trying to hide that it’s AI—hence writing a whole post about it—I just don’t want people tuning out or getting disconnected from the joke because a software logo is flashing in the corner.
  • The Fix: I made the circular headshot badge in Canva slightly larger than necessary so it comfortably covers the entire corner, keeping the viewer’s focus on Desmond and the punchline.

The Finished Project

The pipeline works. I went from dressing up once in front of my webcam to pumping out multiple TikTok clips without putting the suit back on.

You can see the final Desmond Vance videos live on TikTok:

The Verdict:

I no longer have to set up lights or hit record for every new clip.

I no longer have to open a real video editor just to add text to a 10-second video.

I no longer want to pull my hair out over video production.

Once the template is saved in Canva, shipping a new clip takes under five minutes.

Read more at Build and Bail

The requirements were simple but specific:

• A front page showing overall leaders, split into Men’s and Women’s brackets.
• Clickable sections for individual events (like “Plank Hold” or “Golf Putting”) showing the rules and the current standings.
• A custom point system where 1st place gets 9 points, 2nd gets 7, down to 10th place.
• A hidden admin dashboard where we can add events, enter people’s scores, and let the app automatically calculate who is winning.

The Toolkit

You don’t need to know how to code to build something like this anymore, but you do need to know what tools to tell the AI to use. Here is the basic setup:

• The Brain: Claude Code (an AI that runs on your computer and writes the files for you).
• The Frontend: Next.js and Tailwind (this just means a modern website that looks clean and works fast).
• The Database: Supabase (a free, easy-to-use place to save all our entrants and scores).
• The Hosting: Cloudflare (to put the site on the internet for free).

The Secret Sauce: How to Actually Manage the AI

If you are trying to get an app out of your head and onto the screen, do not write one giant prompt asking the AI to build the whole thing.

If you ask for the whole house at once, the AI will build something that looks like a house, but when you open the front door, the plumbing is connected to the ceiling fan. By the time you notice, it’s too tangled to fix.

Instead, I used a strict checkpoint system. I gave Claude a master to-do list and forced it to stop after every single step so I could verify it worked.

• Step 1: Build the database tables. (Stop and let me check).
• Step 2: Write the math logic that calculates ties and assigns points. (Stop and let me run a test).
• Step 3: Build the public homepage with dummy data. (Stop and let me look at it).
• Step 4: Build the password screen for the admin area. (Stop and let me try logging in).
• Step 5: Build the forms to enter real scores. (Stop and let me try it).

Because I tested step 2 before step 3 was ever written, I knew the math was bulletproof before the AI started building pages that relied on it. This is the secret to rapid prototyping with AI.

The Snag: Getting it on the Internet

The only real headache we hit was when it was time to put the site live on Cloudflare.

• Claude initially tried to use an outdated deployment method.
• It caused the “backend” of our site (the part that saves the scores and checks the passwords) to crash because it was trying to run on the wrong type of engine.
• The fix: I told Claude to rip out the old method and use the modern Cloudflare adapter (OpenNext).

Once we made that swap, the site immediately worked online exactly how it worked on my computer. Note for builders: Always use the “preview” command to test how your site runs on the internet before actually publishing it.

The Finished Project

The final site is live right now at www.awesomeofficegames.com.

It’s fast, minimal, and does exactly what it needs to do. Because we built it in clean, logical chunks, it was incredibly easy to go back at the end and ask Claude to add a few polish features, like a navigation bar for the admin area and the ability to fix typos in people’s names without breaking the leaderboards.

If you’ve got an idea in your head, the tools are ready. Just remember to steer the ship one checkpoint at a time.

Read more at Build and Bail

So a FreshRoast SR800 roast logging app wasn’t a guess. It was the digital version of a thing I already sell. I built Drop Log for me first — I’m the most reliable user I have — but with actual evidence the need is real, not a hunch I talked myself into.

Then I made a string of calls that look like shortcuts and weren’t. Here’s the reasoning.

Why I built it in a single browser tab

The “proper” plan I worked out with Claude had me installing Xcode, Android Studio, Node, a build service — the full native dev gauntlet before writing one line. I looked at that and decided I’d rather build than configure.

So I used Gemini AI Studio. One tab. Describe what I want, it writes the code, builds it, I test it. No local environment, no terminal. That tradeoff cost me some things (below), but I stayed in flow instead of losing a night to installers.

Why it’s an Android roast logger and nothing else (for now)

Because I’m an Android user and I’m tired of being an afterthought. Every app ships Apple-first and Android waits months for a worse version. I built the Android roast logger I’ll actually use. iOS happens later, if ever — the reverse of how everyone else does it.

Why there’s no cloud and no account

The original plan had a backend, accounts, a shared recipe database. I cut all of it. Drop Log is a home coffee roasting tracker that lives entirely on your phone, locally. No login, no server.

• it’s for me first, and I don’t need a community to log my own roasts
• offline-and-yours-forever is a feature next to a roaster in a garage with bad signal

You save your own recipes locally and replay them. If recipe sharing ever shows up, it’ll be because I wanted it — not because a roadmap demanded it.

The paper logbook still exists for the people who’d rather keep their phone away from the heat. Same problem, two formats. They’re not competitors.

The part where the AI lies to you

Building an app with AI in one tab is great until you notice the tool is a relentless optimist. Gemini ended nearly every reply with a victory lap — real quotes:

• “The build compiled with immediate success.”
• “The application compiles perfectly.”
• “robust and production-ready.”

At the same time:

• it couldn’t publish for three rounds (“Developer status does not allow app creation”)
• the version number kept colliding with itself — 1 → 2 → 3 → 4 chasing errors
• the bottom nav buttons just didn’t always work. tap, nothing.

“Production-ready” and “frozen buttons” were true in the same breath. That’s the catch: the tool narrates success while the thing is broken, and your only real job is to be the person tapping the buttons. I caught the frozen nav by describing the exact symptom, swapped the heat to a real 1–9 scale, and added a Start Roast button so the timer doesn’t run before the first bean drops. Stuff you only find by using it.

Where it stands

Internal testing now — me, garage, real roasts, finding what breaks. Public testing next. Then Drop Log becomes the SR800 roasting app I wanted but couldn’t find.

Verdict: KEEP GOING. I built the app I wanted, on the platform I use, for a problem people already pay me to solve on paper. The “limitations” are choices. The only thing the AI got wrong was telling me it was done.

More once it’s public.

Read more at Build and Bail

In his first trip in the book, he lands in a world with a purple sky where his counterpart is a sorcerer apprentice who accidentally froze his entire valley. There’s a talking crow named Pib who has zero patience for either of them. It’s called Into The McNultyverse.

I finished the whole book. Then decided not to publish it as a book.

Before making that call I had Claude pull competitive research on KDP for kids books in the middle grade space. The short version: very difficult to rank, very crowded, and discoverability without an existing audience or publisher backing is rough. A serialized fiction podcast gets distributed by Spotify and Apple for free. The book would’ve needed a marketing push I wasn’t ready for. So the book became a season.

The thing I didn’t expect to find

Full-cast audio dramas dominate the 7–12 space. Mars Patel, Six Minutes, Kaboom — multiple voice actors, cinematic sound design, the whole thing. Great. Also not happening on a solo creator budget.

But there’s a show called Finn Caspian — one narrator, third-person limited, doing distinct voices for each character — that ran 200 episodes across 12 seasons. That’s the model.

And here’s where my own concept accidentally solved my biggest production problem. Every book, Mike meets an alternate version of himself. Same voice, different world. I was always going to need two Mikes. That’s not a casting problem — that’s an ElevenLabs brief. Clone my own voice, adjust the pacing and delivery to be a little slower, a little more formal — and that’s the counterpart. The AI weirdness is actually right for an alternate dimension character.

What the build looked like

I used Claude to research the kids podcast market before writing anything. Then worked through the whole adaptation — book chapters don’t map cleanly to podcast episodes, and the book didn’t have a framing device. Claude suggested a “Counterpart Log” that opens and closes each episode in Mike’s voice, looking back on the adventure. It fits the format perfectly and wasn’t in the original book at all.

Then we wrote all 9 episode scripts. Full book adapted into a full season. About 2.7 hours of audio.

The stack:

• Audacity for recording and editing
• ElevenLabs for the counterpart voice clone
• Buzzsprout for hosting and distribution
• Gemini (Lyria 3) for the show’s music sting

Where it is right now

Scripts are done. Logo is done. Recording hasn’t started. Launch date TBD.

The plan is to record all 9 episodes before publishing any of them, drop 3 on launch day, then weekly from there. I’ll document the whole thing here — the recording setup, whether the voice clone actually works, and what it sounds like when a 43-year-old tries to voice a 10-year-old convincingly.

Coming soon (unless I bail).

Read more at Build and Bail

Then I tried to deploy it to Cloudflare Pages.

Three days, four separate problems, one leaked Supabase password. Here’s the autopsy.

Problem 1: The login redirect loop

Signed in. Got bounced back to login. Signed in again. Bounced back again. Rinse and repeat until I started questioning my life choices.

Cookie writes from server actions weren’t persisting on Cloudflare’s edge runtime. The fix:

• Move the sign-in call to a browser client
• Use a hard window.location.href redirect after success
• Stop trying to be clever with server actions for auth on the edge

Not elegant. Works.

Problem 2: “Supabase env vars: (none found)”

I’d set the NEXT_PUBLIC_* variables as Secrets in the Cloudflare dashboard. Seemed reasonable. Secrets are for secret things, right?

Wrong.

• Next.js inlines NEXT_PUBLIC_* vars at build time
• Secrets in Cloudflare Pages aren’t exposed at build time
• So every Supabase call crashed with undefined credentials

Fix was moving them into wrangler.toml under [vars] as plaintext. I added a note to .env.example so future me doesn’t do this again.

Problem 3: 500s on every static chunk

This is where I burned most of the three days.

Every JS and CSS file under _next/static/* was returning empty-body 500 errors. Build output looked fine. Logs were clean. Everything was correct. Except nothing worked.

I went down a rabbit hole patching _routes.json, which produced a routing overlap error that ironically proved the routing was fine all along.

Root cause: the Pages project itself had a corrupt asset bundle. Deleting and recreating the project fixed it in about 90 seconds.

The signature to watch for, if anyone else hits this:

• Empty-body 500s on static assets
• server: cloudflare in response headers
• No cf-cache-status header at all
• Build log shows success

If you see all four, stop debugging the code. Delete the Pages project and start over.

Problem 4: My Supabase password ended up in my browser history

At some point during all this, a form submission fell back to a GET request because the JS hadn’t loaded yet. My password got stuck in URL query strings. Which means it’s in my browser history. Which means it’s plausibly in Cloudflare’s edge logs too.

I rotated the password. You should probably assume any credential that’s ever touched a form has leaked somewhere.

What actually shipped

A working content calendar with:

• Supabase auth that doesn’t loop
• A weekly calendar view for scheduling across platforms
• Status tracking (draft / scheduled / posted / flopped)
• A quick-add modal so I can dump ideas when they hit
• Hosted on Cloudflare Pages for free

The meta part: I built this specifically to schedule posts like this one. The first post on the calendar is a post about the calendar.

Time breakdown

• Actual building: ~30 minutes
• Waiting for Cloudflare builds: a lot
• Chasing the wrong theory on problem 3: at least an hour I’m not getting back
• Total wall clock: 3 days

The real lesson

Deploys lie. When every layer says “success” but nothing works, the infrastructure itself might be broken in a way that doesn’t surface in logs. Recognize that pattern earlier next time.

Also: I could have just used Notion. I know. I know.

Read more at Build and Bail

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