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

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