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

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

Every Tuesday I drop two business ideas I’d hand to someone and say “go build this.” These are ideas I’m specifically not building — because I already have too many projects running, or because I’d lose interest by Wednesday, or because the idea is dumb but might work anyway.

Two reasons the ideas are free:

• Ideas aren’t the bottleneck. Shipping is.
• If you build one, it becomes a case study. Everyone wins.

Each Tuesday post includes:

• The pitch
• Who it’s for
• The stack I’d use (links to my tools page)
• Weekend-build estimate
• How to monetize it
• Why I’m not building it
• A DIY path and a “have me build it” path
• The exact prompt I’d use in Claude to plan the whole build

That last one is free if you want it. Drop your email in the block after each idea and I’ll send it over.

This week: one that could actually print money, and one that probably shouldn’t — but might anyway.

Idea 1: Invoice Nudge

One-liner: A dead-simple tool that follows up on unpaid invoices so you don’t have to.

Who it’s for

Freelancers, consultants, agencies — anyone who’s sent a $2,400 invoice into the void and forgot to chase it for three weeks.

How it works

• You CC your invoice email to a custom address
• It parses the client, amount, and due date
• If unpaid by the due date, it auto-sends follow-ups on day 3, 7, 14, and 30
• Tone escalates — polite, then firm, then “interest charges apply”
• Reply “paid” to any thread to mark it closed

Suggested stack

• Next.js 14 (App Router) + Tailwind + TypeScript
• Supabase for auth and database
• Postmark for inbound email parsing (does 80% of the work)
• Stripe for subscriptions
• Cloudflare Pages for hosting

Build time

One weekend. Two if you’ve never touched inbound email parsing before.

Monetization

• Free: 3 active invoices
• Pro: $9/mo, unlimited
• Agency: $29/mo, multi-seat

Why I’m not building it

I don’t freelance. It’s not my problem, so I’d lose interest by day three. But if you freelance, this is a real business — boring, useful, and people will pay for it.

Ship it yourself or have me ship it

• DIY: Stack above. The only hard part is inbound email — Postmark’s parse endpoint covers most of it.
• DFY: I’ll build it in a weekend and hand you the keys. Book a call →

Get the planning prompt

Every project on this site starts with a 30-minute Claude chat that turns the idea into a sequence of Claude Code prompts. Drop your email and I’ll send you the exact planning prompt I’d use for Invoice Nudge — run it yourself, get your own build plan, ship it.

I'm looking to build an website called Invoice Nudge. It's a recurring SaaS — auth, billing, multiple users, admin panel, inbound email parsing. It should be a dead-simple tool that follows up on unpaid invoices so you don't have to. Ask any questions then give me the prompts needed to build the website in Claude Code. I'd prefer to use the following stack but am open to other free options: 
- Git hub as repository
- Next.js 14 (App Router) + TypeScript + Tailwind CSS
- Supabase for any minimal data storage (orders, generated outputs)
- Cloudflare Pages for hosting

Idea 2: Out of Office as a Service

One-liner: A service that writes a believable out-of-office auto-reply and — for an extra fee — generates fake vacation photos to post on LinkedIn.

Who it’s for

People who need a mental health day but work somewhere that requires a paper trail.

How it works

• Pick a destination (Portugal, cabin in Vermont, “visiting family”)
• AI writes the OOO message with a realistic return date
• AI generates 2–3 stock-looking vacation photos
• Optional: drip-schedule a “sending this from the road” LinkedIn post for day three

Suggested stack

• Next.js 14 + Tailwind + TypeScript
• Supabase
• Any image generation API
• Stripe for one-time payments

Build time

A weekend. The landing page is four hours.

Monetization

• $19 per trip
• $49 deluxe with photos
• $99 full alibi with scheduled LinkedIn post

Why I’m not building it

The unit economics are bad unless it goes viral. Building a joke business that needs to go viral to work isn’t a plan — it’s a hope. But if you think you can market it, it would print money for a month. For some people, a month is enough.

Ship it yourself or have me ship it

• DIY: Most of this is a prompt and a form. Landing page in four hours.
• DFY: I’d rather build this for someone who thinks they can sell it. Book a call →

Get the planning prompt

OOO as a Service is a different build — one-shot generator instead of a recurring SaaS — so the planning prompt is tuned for that. Drop your email and I’ll send it over.

I'm looking to build an website that writes a believable out-of-office auto-reply and — for an extra fee — generates fake vacation photos to post on LinkedIn. Ask any questions then give me the prompts needed to build the website in Claude Code. I'd prefer to use the following stack but am open to other free options: 
- Git hub as repository
- Next.js 14 (App Router) + TypeScript + Tailwind CSS
- Supabase for any minimal data storage (orders, generated outputs)
- Cloudflare Pages for hosting

Recap

• Invoice Nudge: Real business. Boring. Would probably work.
• Out of Office as a Service: Joke business. Would also probably work. Briefly.

Ship one. Tell me.

FAQ

Are these ideas actually free to use?

Yes. Take them, build them, sell them, keep everything you make. The only ask — tell me if you ship one so I can feature you.

What do I get when I opt in for the planning prompt?

One email. One prompt. Paste it into Claude and it generates the full build plan — stack decisions, schema, API structure, and the sequence of Claude Code prompts to actually build it. Takes about 30 minutes of back-and-forth. Same process I use for every Build and Bail project.

Why give away ideas (and prompts) that could make money?

Because I can’t build all of them. The pipeline is infinite. Bandwidth is finite. If an idea sits on my list for six months, it’s not getting built — someone else might as well. And if the prompts help you ship faster, that’s the whole point.

What’s the stack you usually recommend?

Next.js 14 App Router, Tailwind, TypeScript, Supabase, and Cloudflare Pages. Full breakdown on my tools page.

Can I hire you to build one of these?

Yes. Every Tuesday post includes a “have me build it” link. Typical engagements: a weekend MVP handoff, a build-and-launch package, or a consulting session where I plan the whole thing with you.

When does the next Two Free Tuesday drop?

Every Tuesday (unless I bail on this series).

More from Build and Bail

• The tools I use to ship every project
• How I built and listed WhoStat on Flippa
• Emergency Pants: the pants delivery service that shouldn’t exist

See you next Tuesday.

Read more at Build and Bail

Episode 2 of the Build and Bail podcast is live, and it’s the canonical Build and Bail story.

It started with a web form. I needed a fake business name and my brain handed me “Emergency Pants For When You Poop Yourself.” Two and a half hours later I had a fully branded site.

What got built:

• A real homepage with a real domain
• Tiered pricing (because of course there’s a premium tier)
• A kids package
• A facility cleaning add-on
• A poop emoji favicon
• An AI-generated commercial featuring a guy in flannel saying “we’ve all been there before”

Total cost: $0. Total time: 2.5 hours. Total dignity: questionable.

This is the build that taught me the whole pattern — pick the dumbest idea you can defend for 30 seconds, ship it, see if anyone laughs, move on. Emergency Pants is the reason Build and Bail exists.

Listen below. The commercial is in the show notes and on the build log if you want to see it for yourself.

Podcast Transcript

It started with a web form. I was testing something out and needed to type in a fake business name. You know how your brain just fills things in sometimes? Mine filled in “Emergency Pants For When You Poop Yourself.”

I laughed. Then I stopped laughing. Then I thought — wait. Is this actually a business?

One hour later I was building a website.

This is Build and Bail. Build the idea stuck in your head, 

The idea:

The premise is simple. You’re out in public. Something goes wrong. Catastrophically wrong. And now you need pants. Fast.

Emergency Pants delivers fresh clothes — pants and underwear — to your location in central New Jersey within ninety minutes. A hundred and fifty bucks. All the clothing is sourced from local thrift shops. The delivery van has the word “Laundry” on the side, in quotes, because discretion matters but honesty matters slightly more.

Once I started building, I couldn’t stop adding features. Kids package — drop-offs at schools, sports fields, birthday parties. Because children are absolutely not immune to poop emergencies. A four-hundred-fifty-dollar facility cleaning option for the really bad situations. Then I expanded coverage to include pee incidents too, because fairness.

And then I made a little brown poop emoji favicon. So when you have the site open in your browser, there’s a tiny poop icon in the tab. Absolutely essential. Non-negotiable feature.

The commercial:

The site looked legit. Too legit. At that point you kind of have to make a commercial.

My original plan was to film it myself. Use my family as the cast — real people reenacting various public poop emergencies. Great creative vision. Then a monster snowstorm hit New Jersey and killed that plan immediately.

So I went to Google Flow, which is an AI video tool in Google Labs. I’d used it a little before but hadn’t really pushed it. I asked it to generate three scenes of everyday people having accidents out in public. Relatable content. Then I generated the star of the commercial — a working-class guy, early forties, jeans and flannel, pulling a small bag out of a van and walking toward a building. His line: “We’ve all been there before. Living life. Then poop happens.”

That’s the tagline. That’s the whole pitch. If you don’t connect with that on a human level, I don’t know what to tell you.

I extended the clip to have him walk inside and deliver the rest of the sell, pulled some screenshots from the website, added audio, then brought everything into Canva to trim it up, drop in the logo, add the URL.

The result:

Two and a half hours. That’s what this took. Some of that was just waiting for AI prompts to generate. The rest was me building a fully branded, fully functional website for a company that delivers emergency pants to people who’ve pooped themselves in public. With a commercial. And a poop favicon.

There are real businesses with real funding that don’t look this put-together. I built this because a web form needed a fake name and my brain wouldn’t let it go.

Is it a real business? Almost certainly not. Could it be? That’s the weird part. The infrastructure is there. The site works. The pricing makes sense — thrift shop pants marked up with a convenience fee. Local delivery in a discreet van. There’s a version of this that actually exists and I’m not sure whether that’s inspiring or terrifying.

But that’s the point. You don’t know which ideas are real until you build them. And you can build them in an afternoon now. The tools exist. The excuses don’t.

Outro:

Full build log is on the site. The commercial is there too. And if you want to see the actual Emergency Pants website — fully functional, completely absurd — there’s a link in the show notes.

Next time you have a dumb idea, don’t write it down. Build it. It takes less time than you think, and it’s way more fun than planning.

I’m CT. This is Build and Bail.

Want the system in PDF form? Grab the free Build and Bail Playbook: buildandbail.com/playbook

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

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

The Problem

White Knuckle Golf has three text designs. Three. And I was already spiraling about listing architecture.

Should every text-on-every-product be its own listing? Should I group by product with text as a variant? Should the text be the hero and the product be the dropdown? There are entire Etsy subreddits dedicated to this question and somehow everyone disagrees with everyone.

So I did what any self-respecting Build and Bail operator does — I asked Claude.

What Claude Came Back With

Claude framed the whole thing as a tradeoff between three options, and honestly the framework alone was worth the conversation:

Option 1: One listing per text × product combo. Maximum SEO surface area. Every listing gets its own title, its own keywords, its own chance to rank. The downside is you’re spreading reviews thin and managing a ton of listings. Claude called it the “maximum SEO play” — best reserved for your top performers, not your whole catalog.

Option 2: Each product, multiple text options as variants. The classic Shopify approach. Clean storefront, consolidated reviews, easy to manage. But the listing title has to go generic — “Funny Golf Ball Markers” instead of the actual phrase that someone’s searching for. Good for a store with existing traffic. Not great when nobody knows you exist yet.

Option 3: Each text design, multiple products as variants. This one was the spicy take. The phrase is the product. Nobody’s buying “a ball marker” — they’re buying “Here Comes The Money Shot” This approach makes the text the hero and lets you bolt on new products (markers, end caps, whatever’s next) without restructuring everything.

Claude’s recommendation was a hybrid: Option 3 as the primary store structure, with a handful of Option 1 single-combo listings on Etsy for your best phrases.

Then I Said “I Only Have 3 Designs”

And Claude basically told me to stop overthinking it.

The actual advice: on Etsy, list every text × product combo individually. With 3 designs and 6 products, that’s 18 listings. Etsy rewards individual listings with their own search placement and reviews. At this scale, the “management nightmare” isn’t a nightmare — it’s a Tuesday afternoon.

On my website, go text-as-hero with product variants. Keep it clean, keep the brand identity front and center. The site has no organic traffic yet anyway, so the SEO architecture matters way less than making the shopping experience feel intentional.

And then the real gut punch: “The real priority at 3 designs isn’t listing structure — it’s getting to 10-15 designs so the catalog feels like a real brand and not a side project.”

What I Actually Decided

Etsy: individual listings per combo.

Website: text-first pages with product toggles.

Exactly what Claude said. Took about 5 minutes of conversation to go from “paralyzed by options” to “clear plan, moving on.”

The Takeaway

This is exactly the kind of decision that kills momentum for solo operators. You can spend three days reading forum threads about Etsy SEO or you can have a structured conversation with an AI that understands your specific situation — 3 designs, two sales channels, zero traffic — and gives you a framework that actually scales when you’re ready for it.

The framework matters more than the answer. Now I know why I’m structuring things this way, which means when I hit 10+ designs, I already know what changes and what doesn’t.

But for now? Ship the 3 listings. Make more designs. Stop architecturing and start selling.

Build Status: Strategy locked. Listings almost live.
What’s Next: Finish the website and build the Etsy shop. More designs. The catalog is the bottleneck, not the structure.
Bail Risk: Low. This one’s a real business.

Read more at Build and Bail

The idea hit me while hovering over a suspicious bit.ly link — you know the feeling. You don’t know where it goes. You don’t trust it. You click it anyway because you’re brave and/or reckless. But what if the link had been longer? More path segments. More parameters. More words like “verified” and “enterprise” and “secure” baked right into the URL? Would you have trusted it more?

I would have. That’s the whole premise.

URLongener® is a website that takes a short URL and makes it significantly longer. It does not redirect anywhere. The output URL is not clickable in any meaningful sense. It looks extremely professional.

The Build

Zero dollars. One weekend. The concept went from thought to deployed product faster than I could talk myself out of it, which is the whole point.

The tool lives at bizbyct.com/urlongener. You paste in a URL. You get back a longer version of that URL. The expansion algorithm — and yes, I’m calling it that — appends trust signals, compliance indicators, enterprise path segments, and a full UTM parameter suite to whatever you put in.

Example:

Input (suspicious): https://bit.ly/3xK2mPq

Output (trustworthy): https://bizbyct.com/urlongener/redirect/enterprise/v2/destination/verified/secure/professional/trustworthy/link/go/3xK2mPq?utm_source=urlongener&utm_medium=expansion&utm_campaign=confidence&session=authentic&validated=true&expanded_by=URLongener_Professional_Enterprise_Grade_URL_Expansion_Platform_v2_dot_0

Does that URL go anywhere? No. Does it look like it was generated by a serious organization that thought carefully about it? Absolutely.

The Numbers (Full Transparency)

The 47 elongations are all mine. I have used this tool 47 times despite it not functioning. I find this acceptable.

The Business Model (Theoretical)

There’s a freemium SaaS structure in place:

• Free — 10 elongations/month, standard trust signals
• Professional ($12/mo) — unlimited elongations, maximum confidence parameters, extended path segment library
• Enterprise (custom) — branded path segments, custom domain elongation, dedicated account manager (me)

Payment infrastructure does not exist. The product does not redirect. These are known issues.

The Verdict

URLongener generates longer URLs. What those URLs do is between you and your browser. I built it for nothing, it has earned nothing, and I have used it 47 times anyway. That tracks.

If you’d like a longer URL that goes nowhere, it’s live and free: bizbyct.com/urlongener

If you’d like to invest in this at an $800K pre-money valuation, the pitch deck is also live: bizbyct.com/pitch-urlongener

Current MRR: $0. Projected MRR: the math on this one is unclear.

URLongener® is a registered mark in CT’s notes app. Longer URLs are not proven to be more trustworthy. URLongener operates on the assumption that they are.

Read more at Build and Bail

That feels like it needs an explanation.

When I built BizByCT, the whole joke was presenting dead projects with the gravitas of a Series B pitch deck. Abandoned calculator tools. A pants delivery service for emergencies. Formatted like someone was actively soliciting institutional capital. The absurdity was the point.

But while I was building the site itself, I kept thinking: this is actually a useful workflow and nobody talks about it this way. Zero installs. Zero IDE. Just a browser, a GitHub account, Cloudflare, and Claude Code doing the heavy lifting. I shipped the whole BizByCT site that way. So I wrote it up and buried it in the nav of my fake investor site, which is exactly the kind of decision-making that defines this brand.

What the tutorial actually covers

The short version: how to go from “I have an idea” to “I have a live website with a real domain” without touching a terminal, downloading an editor, or pretending you understand what a Node.js version conflict means.

The stack is three tools: Claude Code (browser-based, connects directly to your GitHub repo), GitHub Pages (free hosting, deploys automatically on push), and Cloudflare (DNS, SSL, free tier handles everything you need). Claude Code writes the code, commits it, and pushes it. GitHub serves it. Cloudflare makes it look like you know what you’re doing with a real domain.

The example I used in the tutorial is a fictional dog walking business called Good Boy Walks. I prompted it, built it live, and published the actual output so you can see exactly what Claude Code produces when you give it a real brief. The site is there. It’s real. No dogs were walked.

Why this matters for the Build and Bail workflow

The whole Build and Bail philosophy is that the build phase should be fast and honest. You’re not trying to build something perfect — you’re trying to find out if something works before you spend six months on it. That means the gap between “I have an idea” and “something exists on the internet” needs to be as small as possible.

This tutorial closes that gap. A few hours, three free (or cheap) tools, and you can have a live, real-domain website without asking a developer friend for a favor or watching a three-part YouTube series on web hosting. That’s the point. The faster you can ship, the faster you find out if the idea has any pulse.

I built the tug of war calculator the same way. The BizByCT site itself, same way. When the build is this fast, bailing isn’t even that painful.

The footnote at the bottom

The tutorial ends with: “This tutorial describes a real workflow. The dog walking business is fictional. No actual dogs were walked during the making of this guide, though several were considered.”

That’s the energy. The workflow is real. The business is fake. The lesson applies to both.

Go check it out at bizbyct.com/tutorial — and if you’ve been sitting on an idea because you don’t know how to build the website part, this is your excuse to run out of reasons not to.

Read more at Build and Bail

It started the way most of my projects start: with a question nobody asked. How many hamsters running in wheels would it take to power my website?

I typed it into Claude, fully expecting a one-line joke. Instead, I got physics. A hamster generates about 0.5 watts on a wheel. They only run about 6 hours a day. A basic web server draws around 400 watts. The math landed on 3,200 hamsters working in four rotating shifts, each group tricked into a different circadian cycle with controlled lighting.

Claude didn’t just give me a number. It gave me a shift schedule, a facility layout with color-coded rooms, a rest day rotation, and a job title: Hamster Ops Manager.

The math: 400W ÷ 0.5W per hamster = 800 running at all times. At 6 hours per hamster per day, you need 4 shifts × 800 = 3,200. Add a rest rotation and buffer, and you’re looking at about 4,500 hamsters total.

At that point I knew this had to be a video.

From Chat to Script

I asked Claude to write me a production script for a 10–15 second video. It came back with a full cinematic breakdown: warehouse layout, props list, shot-by-shot timing, crew roles, even three budget tiers. Way too detailed for what I needed.

I told it I was using an AI video tool and to simplify. It immediately stripped everything down to four scene prompts with paired visual and audio direction, each one ready to paste into a generator. That’s the version I used.

The Workflow

1. Ask the dumb question — Claude did the math, designed the shift system, and mapped out the whole facility.
2. Generate the script — Asked Claude for a video script, iterated once to simplify it for AI generation, and added audio cues for Flow.
3. Paste into Google Flow — Dropped each scene prompt into Flow / Gemini. It handled visuals and audio together.
4. Add text overlays — Quick pass to add the three text cards: hamsters per shift, watts, and the final tagline.

The Tools

• Claude (Anthropic) — math, script, prompts
• Google Flow / Gemini — AI video generation

That’s it. Two tools. The entire process from dumb question to finished video happened in one sitting. No footage was shot. No stock video was licensed. No hamsters were harmed or employed.

Watch The Process

Watch The Result

What I Learned

The interesting part wasn’t the hamsters. It was the feedback loop. I started with a throwaway question, got a surprisingly detailed answer, and realized the answer itself was content. From there, Claude adapted its output three times: first a full production script, then a simplified AI-ready version, then audio cues for a specific platform. Each iteration took one sentence of direction.

The gap between “idea” and “finished thing” is collapsing. Not because the tools are perfect, but because the iteration cost is nearly zero. A bad prompt costs you ten seconds. A good one gets you a video.

Will AI-generated video replace real filmmaking? No. But for a weird idea that lives in the space between shitpost and science, it’s exactly the right tool.

3,200 hamsters. 4 shifts. 1 website.

Keep chasing your silly ideas.

-CT

Read more at Build and Bail