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

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

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

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 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