John Nunemaker

The Friday Deploy: Your PR Shouldn't Make Your Stomach Hurt

Fri, 06 Nov 2026 15:30:00 GMT

Garrett and I recorded episode two of The Friday Deploy. We started with personalized interfaces and ended with a basketball app and me casually mentioning that I’d rewritten a chunk of Flare to run on Cloudflare. As one does.

But the thing I keep coming back to is the pull request that makes your stomach hurt.

I’ve made plenty of those lately. Ask AI to build something. Have another model review it. Fix the findings. Review it again. Find more things. Fix those. Pretty soon the little change you wanted is 3,000 lines and you don’t want to merge any of it.

For a while, my response was to keep going. Surely one more review would make me feel better.

Sometimes the better answer is to throw it away and ask for something smaller.

Put an End on the Review

I wrote up the Nunebot process already, so I won’t repeat the whole thing here. The detail that helped most: after the first review, review the fixes, not the entire change again. Bound the loop. If it’s still a mess, stop.

Garrett came at the same problem from the UI side. His Workbench process runs deterministic checks, gets other models to look for holes, and tracks findings against the state of the code where they were found. Each finding needs a decision. Fix it, dismiss it, or bring it to him. Don’t just keep rediscovering the same thing forever.

We took different paths, but ended up wanting the same thing: a small change with enough proof that merging it feels obvious.

Quiet Support Isn’t Proof

This came up while we were talking about moving Fireside’s file storage to Cloudflare R2.

Support was quiet. Which is great! Except when you’re changing something important and start wondering if it’s quiet because everything works or because nobody has tried the thing yet.

So I asked the agent to watch more than errors. Successful MP3 uploads. Images. Transcripts. Cloudflare errors. Honeybadger. Support requests. Tell me what’s actually happening while we roll this out.

It started with short check-ins and backed off as we gained confidence. We weren’t just waiting for somebody to tell us we’d broken their podcast.

That distinction feels important. No errors is one signal. People successfully doing the thing you changed is another.

Two Flags, Two Decisions

We separated R2 reads from R2 writes.

First, read from R2 while the old storage was still receiving writes and replicating them over. Get comfortable with that. Then switch writes.

The flags gave us smaller decisions instead of one giant moment where everything had to change at once. They also made us be specific about rollback. Switching writes back while leaving R2 reads on was one thing. Switching reads back after new files had landed only in R2 would mean copying those files back first.

A flag is useful. Knowing what the flag can safely undo is useful too.

One version of this work wanted another database column to track the switch. I wasn’t convinced we needed it. Starting over with a simpler approach helped get the implementation back to something I felt good about.

More of the Fun Stuff

My favorite part of the conversation was Garrett talking about the iOS app he’s building to help analyze basketball shooting mechanics.

He coaches. He likes basketball, information design, and math. Now he can put those things together without first taking a detour through learning an entirely new platform. He’s going to the gym, recording shots, testing with other people, and iterating.

He still runs reviews and tests. He’s still making decisions. He’s just spending more of his time on the parts he enjoys.

That’s the bit I’m excited about too. Smaller changes. Better evidence. Less time wrestling with a PR I don’t want to merge.

Listen to episode two, or start with episode one. You can subscribe on Apple Podcasts, Spotify, or RSS.

Don't Make a Human Do What AI Is Amazing At

Thu, 29 Oct 2026 16:00:00 GMT

Last weekend we were camping. Fall break. Glorious northern Indiana weather. My kids were fishing with grandpa, so I went for a walk around the campground (to check out the other rigs as dads do). Somewhere along the way I opened T3 and told Nunebot to do another run. Merge, merge, merge, run it again, merge, merge. Just getting some exercise and enjoying the fall weather.

Between Saturday and Sunday I merged 113 pull requests. Definitely the most in a two day span in the two decades I’ve been doing this.

I know how that sounds. But I honestly like this more than games, mindless scrolling, or Instagram. It’s relaxing for me. Read a PR, it makes sense, merge. Little dopamine hit. Next.

I’ve explained Nunebot to a handful of people now, and every time I think, why am I not writing this down? So here it is. When I lay it all out, it sounds stupidly obvious. But a couple of the details took me a while to figure out, and those are the parts that make it work.

What Nunebot Is

Nunebot is a prompt. That’s it. It’s a markdown file in a private git repo I call brain. I tell an agent to read it and run it, and it makes a pass over my repos in priority order. For each repo it:

Tends the PRs it opened on earlier runs.
Gathers context.
Picks one change that’s an obvious yes.
Builds it in its own worktree.
Runs /simplify on it, then /qa, and finally /codex review (with a few rounds of fixes at most).
Proves it works.
Opens a PR labeled nunebot and gets CI green.
Writes down what it did in brain.

It never merges, deploys, or changes anything in production (yet). I merge. Most of my apps deploy on merge, so that’s the whole job for me for these types of changes.

Why the name? I needed something, and Nunebot is funny.

Why I Built It

The goal is kaizen. Small improvements to every app, all the time, without me ever doing the tedious stuff AI is better at anyway. Three things drove it.

The tedium. I’m not trying to get it to build all my features. What I want is to never update a dependency again. I want to never fix a Honeybadger error by copying it into an agent and saying “fix this” (or by using their great MCP).

I don’t want to remember to run a GEO audit, an SEO audit, or a security audit. My teammates and I were doing all of this chore work by hand across Box Out, Fireside, Flipper, and Flare. I want all of it to run all the time and just pop up PRs. And I just say yep, yep, yep, yep, yep. Then it goes again.

Getting better without me. None of these PRs moves the needle on its own. That’s exactly why they never got done. But all together? Performance problems get fixed faster. Security holes get closed faster. Customers are happier because things just work. The marketing keeps getting better whether I’m paying attention or not. The prompt opens with the framing I care about most:

Software is not a factory. A factory builds identical widgets to a fixed spec and is done. Software changes every day: customers, scale, and requirements shift, so a perfect up-front spec never exists. Treat each repo like a painting you come back to: make one deliberate improvement per pass, and leave it better than you found it.

Letting AI do what it’s great at. AI is amazing at a tight, focused, 40 line change with a test that proves it. It’s a lot less amazing at 3,000 line PRs. I know because I kept making them. I’d keep looping review and fix, trying to get to zero findings. Sometimes it never got there. It just kept finding things, the code kept getting more complicated, and pretty soon I had a 3,000 line PR that made my stomach hurt and I was afraid to merge. I never want to be there again. So the whole thing is designed around small.

Step One: Give It All the Context

Nunebot can’t do much if it can’t see what I see. So the first thing is MCPs for everything that tells me what’s happening in production: Honeybadger for errors, Flare for performance, PlanetScale query insights, Crisp, Help Scout, and Jelly for support across the apps, plus Cloudflare for costs, the Linode CLI for the servers behind my personal stuff and Fireside, and the Heroku CLI for Box Out and Flipper Cloud (for now).

The second thing is knowing what I care about. That’s brain. It’s a private repo full of markdown: a short Now list, ranked priorities, a file per project, an inbox for random ideas, a list of things only I can do, and a folder for Nunebot. It’s unstructured and wildly inefficient. Justin Searls told me I should use SQLite with Litestream so all my computers share the same database, and he’s probably right. But I already had the repo, agents already know how to commit, and it works. I’ll get this tuned and swap out the component later.

Brain is the part that matters most. Nunebot reads it first, and if brain has anything for a repo that a PR can solve or move forward, it works on that, even when something else looks easier or more interesting.

Step Two: Decide What to Do

The repos are in priority order. Revenue first: Box Out (it makes the most) and Paint (Box Out’s renderer), then Flipper Cloud, Flipper, Flipper Pro, and the Flare repos, then Fireside. Garrett is primary on Fireside, so I just do little things there when I have extra tokens. Then everything else: Pitch In Now, PreachIndex, HTTParty, South Bend Watch Co, workspace, this site, and so on.

When brain has nothing for a repo, it looks everywhere else:

Cheap stuff, every run. The repo’s docs/backlog (markdown files of things we want to do, with the research and context ready for when we pull the trigger, like a fleshed-out GitHub issue that lives in the repo), GitHub issues, support conversations, Honeybadger, metrics, and a quick dead code scan.
Saved findings. Every audit’s results land in brain, one file per repo (nunebot/findings/<repo>.md). Whatever gstack’s /cso, Cloudflare’s security-audit skill, /geo-audit, or a cost or dead code review turned up, numbered and marked open, PR’d, merged, or rejected. The next run picks from them without redoing the audit. Like, “the last /cso run found all this stuff and we haven’t fixed the P1s. Let’s fix those.”
Expensive audits, only when the backlog is thin. Security (alternating /cso and security-audit), /geo-audit for SEO and AI search, a cost review, or a dead code review. Whichever is most overdue.

Then it picks one thing. This is the part that keeps it small:

The bar is an obvious yes from me: a PR I’d merge after a quick read. Either the work is genuinely small, or it’s a small next chunk that is complete and useful on its own. Never part 1 of 20: no scaffolding, half-built features, or setup that only pays off in later PRs.

It has to be real (evidence it matters), valuable, reviewable in minutes, and provable. And if nothing clears the bar? “Skip the repo and explain why. No PR beats a weak PR.”

The cool thing is I’ve watched it break bigger tasks into smaller ones on its own. It doesn’t want to make a big diff, so it figures out the first piece it can get to production.

Subtracting, not just adding. If you run all of this and never delete code, you end up with a lot of code. The best code is no code. So every pass includes a quick dead code scan, and the prompt tells it to keep a mix. If a repo’s recent Nunebot PRs have all been additions, a solid removal wins a close call. Unused methods, routes, CSS, JS, gems, packages. Doesn’t matter. 46 of the 250 merged PRs deleted more than they added.

It doesn’t always get it right. It opened a 2,248 line Fireside PR removing marketing controllers and views I’d unrouted in a cutover. I closed it: “Not ready to do this. It was automated by nunebot. I think we leave for when we resurrect them.”

Taste

That brings me to taste. Every time I close a PR, ask a question, or say no, it goes into nunebot/taste.md. After that Fireside PR, it wrote itself a rule called “Unrouted isn’t always dead”: code I recently unrouted on purpose is parked, not dead.

At one point an agent suggested I rename Flare, since there’s already another Flare out there. Nope. Now there’s a rule: “I’m not renaming Flare, I love the name.”

My favorite one came from a Flipper Cloud security fix. Before merging, I asked what it would do to performance and whether it was mostly additive, meaning it checks more things but won’t break anything existing and legit. Now every PR has a Performance & compatibility section that answers both before I ask.

There are 107 of these rules after 11 days. I’ll need to compact them into the prompt at some point. Live and learn.

Step Three: Build It, Shave It, Try to Break It

This is my current build, and it’s the part I’m most excited about:

Build. Opus 5.5 writes the change and a test that fails on main, in its own worktree with its own ports and databases. Commit.
/simplify. It’s built into Claude Code, and it usually shaves off a good amount of the crappy AI code. Commit.
/qa. This one’s from gstack. It actually uses the thing. If it’s a CLI, it runs the CLI. If it’s an API, it curls it. If it’s in a browser, it clicks through it. After this, I know the code works. Commit the fixes.
/codex review. Also gstack. Codex does an adversarial review and fixes anything legit. Then, and this is the trick, it runs /codex review again on just the fixes, not the whole change. At most three rounds. If Codex is still finding stuff after that, it gives up on that repo, leaves the branch pushed, writes the findings in brain, and moves on.

Reviewing just the fixes is the biggest thing I figured out in October. Before, I’d run a full review, fix, full review, fix, chasing zero findings. Claude especially would go 20 loops finding nits on repeat. That’s how I got the 3,000 line stomach-ache PRs. Now: the code is written, it’s been shaved down, we know it works, and we’ve looked for holes. Ship it.

Here’s one. On workspace#21, round one caught a test stub using Ruby 3 syntax that macOS’s system Ruby 2.6 can’t parse. Fixed. Round two, on just the fix: clean.

One gotcha. gstack is invasive. Mention deploying and it’ll decide to run its whole /ship workflow, rerun all your tests, and redo a bunch of work you already did. It’s built for people who aren’t paying attention, and here, the prompt already is. So my global agent instructions say:

Do not automatically invoke, load, or follow any skill. Only use a skill when I explicitly name it in the current request. The presence of an applicable installed skill is not permission to use it.

Nunebot names each skill explicitly, in order. And since nobody’s watching the run, the prompt says that when a skill stops to ask a question, take the recommended option and note it in the PR.

Step Four: Prove It

I never sat down and designed a PR template. I told it what I care about from a verification standpoint, and it built the PR body so I gain confidence as I read down. Why. What changed. Proof. Performance and compatibility. Review. Risk and rollback.

The top of flipper#1075. Why, what changed, then proof.

Proof is the part I care about. Thorsten Ball from Amp has been talking about asking for irrefutable proof, and it’s so good. Tell Claude to give you irrefutable proof and it will. If it can’t, it tells you why and gives you everything up to that point. (I’ve talked about prove it before. I’m still on it.) Every Nunebot PR needs whichever of these apply:

A test that fails on main and passes on the branch, with both outputs.
The full suite and linters green.
The change seen running: the app, a console session, a script.
Before and after screenshots when a person would see the change.
Before and after numbers for anything that claims to be faster or cheaper.
For removals, the searches and signals proving nothing uses the code.

Here’s a real one. On South Bend Watch Co, any request that blew up returned a bare 500 in production, even when Rails wanted a friendly 422. The root cause was an old Honeybadger patching a Rails method with two arguments after Rails 7.1 started passing three. The fix was a gem bump plus one test. The proof:

Request                                    main   branch
POST /users/sign_in with no token           500      422
POST /users/sign_in, wrong password         200      200
GET /, /watches, /about                     200      200
GET /no-such-page                           404      404

I didn’t ask for that table. I just said I want proof.

Or this one on PreachIndex. Thousands of passage pages all shared the same generic meta description. Now Romans 8:28’s says it’s cited specifically in 26 sermons and within a wider passage in 89. One new helper, one test, 27 lines. Everything’s tested. You can see it works. Why not merge it?

A few public ones if you want to see a whole PR: flipper#1077 (quiets bogus warnings that hit your logs right when a Cloud sync fails), workspace#20 (a pure deletion, with proof nothing uses it), and httparty#869.

A few other things it does:

Steps for me go at the top. If a PR needs something from me, it gets a needs-john label and a checklist up top. When it added a unique index on lowercased emails in Fireside, the first step was to check production for duplicates. I know that. I also could have easily missed it.
Rollback. If anything is risky, it tells me how to roll back. Really helpful when you aren’t reading the code and something goes sideways.
Screenshots, attached. At first it wanted to commit screenshots to a branch. I said I’m pretty sure GitHub has an attach method now. “Oh yes, they do.” Now they’re just in the PR. Most of the time when it says it can’t do something, I say “false,” and it finds a way. It always does.

I got about 20 PRs in and stopped reading the code. I started merging after reading the body. Whoa! I like woke up and realized what I was doing. It was a new level of trust. I’ve always read the models and queries, even when I skipped the views. But the proof is that good, and I’ve built this way all October.

Step Five: Let It Rip

The very first prompt was literally “read this prompt and run it for Flipper Cloud.” It made a PR. Yep, merge. Do it for Box Out. Merge. Do it for Fireside. Merge. Do all three. Merge, merge, merge. Do every repo I’ve committed to in the last year. It’s now opened PRs in 20 repos.

At first it went one repo at a time, so I asked how it would speed things up. Run things in parallel, obviously. But two worktrees of the same heavy app at once isn’t great, and the Box Out suite alone uses about half my CPUs. So it suggested lanes. A heavy lane for the big Rails apps and a light lane for gems and small apps, running side by side. Now it’s nine lanes, three heavy and six light. Each lane gets its own ports, every database gets a worktree suffix, and even the gstack browser gets its own daemon.

I also didn’t want a bajillion PRs sitting open and overwhelming me. So I asked what Dependabot does. It caps open PRs at five. Cool, let’s do five. If a repo already has five Nunebot PRs open, that run skips it.

And the prompt itself? I never wrote it. I opened Wispr Flow and brain dumped. Here’s how I’m building software right now. Here’s where I keep my priorities. Here’s some other random stuff. Then I gave that to Claude and said turn this into a prompt I can rerun from a scheduled task. I ran it on one repo at a time and gave it feedback each time until it was putting out stuff I liked. Then I let it rip.

I hadn’t even read the whole thing until I walked a friend through it this week. I don’t care. I care about the result. Since it lives in brain and gets reread every run, any session I’m in can “add this to the Nunebot prompt,” and it gets a little stronger. It’s 229 lines now, and it’s changed in 19 commits since October 18th.

About day two, Garrett called me. He’s on every repo I’m on. “What are you doing? I need to understand what you’re doing.” He said at first he figured these couldn’t be OK. Then he looked at them, and they were awesome. So I gave him the prompt, and he had his agent compare it to his own skills to see what he was missing.

Guardrails

I started it locked down and I’ve given it more as it earned trust, just like a person. The rules:

Read-only on production and every third-party service. Most of that is read-only access. The Linode and Heroku CLIs can make changes, so there it’s the prompt telling it not to.
No AWS CLI and no AWS credentials.
Never probe or exploit anything in production. Prove security fixes with tests and local runs.
Never message customers, reply to tickets, or close issues.
Never merge, deploy, or flip feature flags.
Infrastructure cost cuts are recommendations in brain. It never applies them.
In public repos like HTTParty, never describe a vulnerability in a PR, commit, or branch name. Brain only, and I handle it.

The Numbers

Here’s every PR labeled nunebot from the first one on October 18th through today:

269 opened across 20 repos. 250 merged, 16 open, and 3 closed without merging.
+14,328 / −6,107 lines across the merged PRs.
The median merged PR changed 43 lines. 190 of the 250 were under 100 lines, 234 were under 200, and only 3 went over 500. The biggest was an npm security bump on this site, and it’s 2,360 lines of package-lock.json.
2.7 hours median from opened to merged.
Biggest day: Sunday, October 25th (sitting in a camping chair). 63 opened, 63 merged.

Now my GitHub contributions graph. For 16 years, 2009 through 2024, I averaged about 1,650 contributions a year. That’s 4.5 a day.

On December 14th, 2025 I turned on a 20x Claude plan to try Opus 4.5. December 14th through March, I averaged 18 a day. That’s 4x. April through July, I dropped back to 5 a day. April and May were prep for a two month summer camping trip, and June and July we were on the road from Indiana to Oregon, Washington, and Montana. Basically, when my kids are out of school, my throughput drops, and I’m ok with that. August and September were back to 18 a day. The first half of October was 31 a day. Since Nunebot started, it’s been 117 a day.

Average GitHub contributions per day.

October 19th through 25th, I had 1,113 contributions in seven days. That’s more than I had in all of 2018 or 2019, and about two-thirds of an average year. That Sunday hit 287 in one day. Before this year, my biggest day ever was 70.

Contributions are a goofy metric. Nunebot commits after every step, so every PR counts several times. Don’t read this as 25x the value. Read it as: the chores are getting done, and I’m not the one doing them.

What’s Next

Right now Nunebot picks whatever it thinks is best. Where I want to go is three stages:

Find work. Security audits, GEO and marketing audits, errors, and performance checks run on a regular basis and just add tasks.
Prioritize. Rank the tasks by impact: the odds we get hacked, revenue, or a customer having a problem we’d like them to not have.
Build and prove. Everything you just read.

I’d say yes, yes, yes, yes to the work at stage two. And once I’ve said yes, I honestly don’t think I need to see the PR. I know that’s a weird thing to say, but the process has been pumping out such good code that my confidence is way up.

I also need a Nunebot GitHub app. Right now it asks questions as me, and then I answer them, also as me. It’s really funny.

The question I ask about every run is simple: did I get a small chunk of code that made my app better, without me being involved? That’s all I want.

And lately the answer is yes about 250 times over.

The Friday Deploy: Changing the Wheels While the Car Is Moving

Thu, 01 Oct 2026 16:00:00 GMT

Garrett and I started a podcast. It’s called The Friday Deploy, and the tagline is the whole point: ship on Friday, sleep through the night.

We already do a marketing and business podcast for Fireside, so we figured, let’s go full on dev with this one. Feature flags, deployments, infrastructure, incidents, product decisions, and all the little practices that let you deploy whenever you want without the sweaty armpits. Sometimes it’ll be just me and Garrett, and sometimes we’ll bring on a guest to walk through what they do.

Subscribe on Apple Podcasts, Spotify, or RSS.

Episode 1: Changing the Wheels While the Car Is Moving

We’re almost exactly two years into owning Fireside, so for the first episode we looked back at what we inherited and how we rebuilt nearly all of it without taking it down. Remember that meme of a car driving on two wheels while people hang out the side changing the other two? That’s basically been the last two years.

Some of the highlights:

What We Inherited. Fireside was eight years old when we bought it. Ruby 2.7, Rails 5, Postgres 9.5, and servers on a version of Ubuntu that had been dead for years. No Puppet, no Ansible, nothing that said “here’s how you recreate this.” Today almost none of that exists anymore. Garrett walked the app up through Ruby and Rails, and I swapped out every single server. The last of the old workers got retired the day before we recorded. (We talked about the early days of that cleanup on the Ruby on Rails Podcast.)

Self-Documenting Infrastructure. The process I keep coming back to: have the agent reverse engineer everything a server does into a markdown file, then tell it to recreate that on a brand new box with no downtime. Same thing for moving off Dan’s Cloudflare account. Document every setting that differs from the defaults, then rebuild it. I punted on that Cloudflare move for a year and eight months. With AI it was done in a sitting. I told the camper version of this story on YAGNI.

Postgres 9.5 to 18 in One Hop. A sane person would have done this in a few jumps. We went from self-managed 9.5 to managed 18 in one shot. Everyone I asked for help just laughed. I waited months for the models to get better, ran the plan past something like six of them, and shrank a bloated table so 80 GB became about 20 GB and the copy only took ten minutes. Reads stayed up the whole time. Feeds and downloads kept working. Podcasters love their downloads, so that part was non-negotiable.

Flipper as the Big Red Button. The go-live moment was flipping a database read-only flag. The whole app switched to read-only mode and showed a friendly message in the studio. I shut off the workers, did the migration, flipped the flag back, and let the workers chew through the queued downloads. Zero support emails. The scariest part was Codex deciding to compact for five minutes right before the switchover.

Taste Is Still the Job. Garrett runs every plan past multiple models. Claude reviews Codex, Codex reviews Claude, Copilot reviews the PR. Fresh eyes without the session baggage catch things. But ask enough agents and you get a pile of opinions, and they will all happily over-engineer anything. Garrett’s agent once tried to add a feature flag to clean up a helper. Knowing what to say no to is taste, and it’s what separates hacking around from shipping software you won’t regret.

Prove It. When we each asked AI to review months of our transcripts and suggest missing skills, the top one for both of us was some version of “prove it.” My biggest tip right now: when you feel anxious and keep adding more prompts to harden something, your problem isn’t the prompt. It’s that you haven’t figured out how to verify it. When I moved to Caddy, the agent tested the new certificates with curl and custom host headers before switching anything. I wouldn’t have even known I could test that.

Read-Only Production Context. All our projects now have a read-only psql script the agent can use against a replica. When it starts overbuilding, I tell it to check our actual scale and then decide. Garrett does the same for UI work. How many customers have 20 podcasts? Not enough to need search in the podcast dropdown. Real data beats guessing.

Keep Deterministic Work Deterministic. Garrett rebuilt Reviewer so agents can discover and run linters, tests, and security checks without burning tokens or freelancing CLI flags. Fewer degrees of freedom, more reliable outcomes.

Scheduled Tasks Are My Beating Heart. Every morning I get a Flare rundown across all our apps: traffic up or down, performance regressions, and what probably caused them. That’s how I found out a crawler was slurping half a million requests a day from one app. Then I wanted it for open source, then Stripe, then QuickBooks. Cron plus AI plus access to context is extremely powerful.

Do We Even Need an Interface? I haven’t opened the Flare web UI since the MCP started working. I just ask Codex what’s slow and it tells me. I floated ops without a UI on Code with Jason, and now I’m seriously considering shipping Flare with no UI except a place to put your credit card. An alert is just a scheduled task. Garrett pushed it further: maybe the interface is assembled on the fly from a link, showing exactly the evidence for the thing that’s wrong and nothing else.

We also got into letting agents carry work all the way to the final approval (I started a worker swap, forgot about it, and got a push notification hours later asking me to approve the cutover), optimistic versus pessimistic locking, and why a feature flag is not a million dollar bank transfer.

Listen to episode one. If you’re the kind of person who wants to deploy on Friday and actually enjoy your weekend, subscribe. We’re going to try and do this regularly.

YAGNI: Camping Chair Development

Thu, 01 Oct 2026 16:00:00 GMT

I joined Matt Swanson on YAGNI to talk about how I build software now across Fireside, Flipper, and Box Out. Some of it even happens from a camping chair.

Some of the highlights:

I’m Not a Craftsman. I always thought of myself as a craftsman. Bespoke furniture. Samurai. Honor. All that. Then on December 14th I turned on a 20x Claude plan just to try Opus and realized nope, I just love shipping stuff and solving problems. These days I read the data models and the queries because those affect how fast things are for customers. JavaScript and view code? I don’t read it. Does it look right? Is it responsive? What’s my Lighthouse score? Good enough.

Stripping Back. I went through a phase of plugins. Compound engineering, gstack, etc. Lately I’m removing things. The tools love to be perfectly correct and solve every theoretical race condition, and you end up with a ball of mutexes that gives me a stomach ache. Is it theoretically wrong? Yes. Does it ever happen in practice? I don’t think so. Less perfectionism, more shipping.

Rewriting Fireside’s Infrastructure From a Camper. When we acquired Fireside, it was on super outdated Ubuntu and Postgres 9.5 with SSL handled by a tangle of Nginx, background jobs, and Redis. I asked what tool does all this and the answer was Caddy. Reverse engineer the current system into a markdown file, describe the new state, let it rip. I missed one host header. In three days I rewrote about 80% of our infrastructure while driving a camper six hours a day and sitting by a fire at night. I’m a scaredy cat about downtime, but it comes up with ways to smoke test everything before you flip the switch that I would never have done before.

Brain or Hands. Matt had a great framing: sometimes you’re the brain and the agent is the hands, and sometimes it flips. I hate being the hands, clicking through some cloud console because the agent told me to. So now I make a temporary API key that expires in an hour and let it do the work. Honestly, I want a new kind of key: read only, plus write access to anything it creates, for a limited time.

Too Many Open Loops. I want a hundred agents cranking on stuff for me all the time. But every agent tool shows you all of them, all the time, and each one sticks in the back of your brain. What I want is something like Railway’s canvas for agents. Every worktree is a box on an infinite canvas. Group the Flipper gem, Flipper Pro, and Flipper Cloud worktrees together, move the rest out of the way, and stop carrying it all in my head. I’m too lazy to build it. Someone please build it.

Prove It. I had the agent go through my past chats and tell me what to turn into skills. Number one was /prove: prove to me that what you did works all the way through. Then I ask how we can break it. Or I just gaslight it with “make fewer network calls” and it goes, “you’re right, I missed these N+1s.” Verification is now the biggest blocker and the hardest thing.

Fake Everything. Matt brought up the idea of having agents build fake versions of third party APIs, like a vibe coded fake Slack that runs next to your app. No more booting on port 3000 so OmniAuth callbacks work. Simulate rate limits and outages with a flag. It reminded me of Toxiproxy from my GitHub availability days. Box Out is all social integrations, so we should totally do this for X and Meta.

Straight to Prod. Garrett asked if we could finally set up staging for Fireside. I don’t use staging anymore. I want to get to prod as fast as I can, because that’s where I feel it now. Matt nailed this: the flow and satisfaction didn’t go away, it just happens at a different point in the process. It used to be when the code was clean. Now it’s when the thing is live and people are using it.

Talking All Day. I’ve had hand and arm problems my whole programming life. Now I talk to my agents all day with Wispr Flow. My only problem is a sore throat. If anything, AI has prolonged my career.

We also got into Cloudflare Tunnel for checking work from my phone, proving to an iCal provider that their feeds were broken (zero bytes since the day they launched their new thing), and why feature flags and APMs matter more when nobody reads the code. APMs are going to have to get a lot cheaper.

Listen to the full episode on YAGNI. I hope you enjoy it. If you want more, I talked about taste and AI on The Hallway Track last month.

Update 2026-10-01: Garrett and I went deeper on the Fireside rebuild, including Postgres 9.5 to 18 in one hop with no downtime for listeners, in episode one of our new podcast, The Friday Deploy.

The Hallway Track: Why AI Rewards People Who Already Have Taste

Wed, 26 Aug 2026 16:00:00 GMT

I joined Chris on The Hallway Track to talk about running Box Out Sports, Fireside, and Flipper while still maintaining open source projects like HTTParty.

We covered a lot of ground in 50 minutes: why I gave up trying to focus, the production problem that led to Flipper, how feature flags change the way teams build software, and why taste might be the real advantage in the AI era.

Some of the highlights:

Giving Up on Focus. I spent years feeling like I was broken because I couldn’t focus on one thing. Everyone tells you focus is how you do something big and great, but I like having a lot of things going. If I get jammed on one project, I can switch to the next most important thing on another instead of dropping to zero. I don’t push one thing forward as far or as fast, but I push a lot of things forward regularly. I finally gave up trying to be someone else about three years ago.

What AI Changed at Box Out. The biggest change is amplification. We have shipped so much in the last six months. But we’re also doing things we would have just said no to before. For years Box Out was built for speed, not customization. Recreating Photoshop in the browser was way outside our niche and not worth the time. Now we’re building a Figma or Photoshop-style template editor because, well, what if we did both?

The Scaling Crisis That Led to Flipper. While working on Words With Friends, we were having scaling problems because a bunch of celebrities started playing and traffic went nuts. I kept rolling out a new caching system and taking down the site because the cache was cold. Then we tried a percentage rollout. I went from 1% to 5% until the cache was warm enough and then let it rip. Feature flags were amazing, but the library we used only supported Redis. I built Flipper so your flags could live in Active Record, environment variables, a file on disk, or whatever made sense for your application.

Feature Flags Change How You Build. Technically a flag is just a quick check to see if something is on or off. But once people start using them, you have to pry them out of their cold dead fingers. You can get unfinished work into production, let the right people try it, and turn it off without another deploy. Everything gets easier, less stressful, and less scary. Chris shared an old newspaper phrase I loved: “demos over memos.” Just get something on a screen that people can react to. If it’s behind a flag, who cares? Nobody sees it. You didn’t break anything. It’s fine.

Maintaining Open Source With AI. I get much better pull requests for HTTParty now. They show up with tests and are often pretty close to ready to ship. AI also helps me research what to work on next and triage security reports. Half the time I read one of those reports and think, bro, I don’t even know what language this is. Now I can understand it, figure out if it’s real, and release CVE fixes faster. That makes a huge difference for a project I maintain in my spare time.

Taste Is the Advantage. Everyone I see exploding with AI already had taste and ideas. They were good without it. They were just constrained by time, brainstorming, research, and all the other stuff around creating a product. AI amplifies that by a different multiplier. It also amplifies bad taste and lets dysfunctional teams make a mess ten times faster. The building was never the hard part. Figuring out what to build was.

Building Games With My Son. We started with AI-generated coloring pages and bedtime stories. Then we made Chickens vs. Zombies, where chickens shoot eggs out of their butts to kill zombies. Obviously. From there we built a Minecraft-ish game with 3D worlds, chat, portals, and Cloudflare Durable Objects. Neither of us had ever made a game. Now he can build what’s in his imagination, play it with his friends, and learn the same things I do when I build software: ask questions, prove that it works, and keep making it better. He used to say he wanted to be an inventor. Now he says he’s going to be a programmer.

We also got into turning open source into a business, the future of runtime controls in Flipper, why AI exposes dysfunction inside engineering teams, and what programming may look like for the next generation.

Watch the full conversation on YouTube. I hope you enjoy it.

Update 2026-10-01: Garrett and I dug into taste, over-engineering agents, and verification in episode one of our new podcast, The Friday Deploy.

Update 2026-10-01: I went deeper on how I actually build with AI now on YAGNI.

Code with Jason: People Buy From People

Mon, 01 Jun 2026 18:47:54 GMT

I went on Code with Jason for the second time. Jason and I got into the Fireside acquisition, how to actually find and finance a business to buy, why support is a product, and where I think developer tools are headed in the AI era.

Some of the highlights:

Why I Bought Fireside. Complete happenstance. I was already paying Garrett Dimon to push Flipper forward, and Garrett had worked on Fireside for Dan Benjamin back in the day. Dan had lost interest and was trying to sell, but it was too big for the small players and too small for the big ones. The math was simple: if I bought it, the profit could pay for Garrett to work on both Fireside and Flipper instead of it coming out of my pocket every month. I’m a long-term person, podcasts aren’t slowing down, and it lined up with the analytics and content hosting I’d done before with Gauges and Harmony. So we did it.

Finding Deals. The marketplaces (Quiet Light, FE International, acquisition.com) are mostly where people list a dying SaaS expecting four to eight times multiples. That’s not reality. A declining SaaS is more like 1.5 to 2.25x. The deals that actually work come through your network, someone who knows someone quietly looking to sell. Stick to what you know. And since the paperwork is identical whether the thing makes fifty thousand or five million, you might as well take the bigger swing.

Financing It. You don’t need a pile of cash. My house was paid off, so I borrowed against the equity. Banks know houses cold, so they’ll lend up to 80% the next day, no questions asked. Farmland is more like 50%. SBA loans were running 10 to 12% at the time versus 5 to 6% for a bank loan, so the margin matters. I took a 15-year term for the low payment even though I plan to pay it off in five to eight. It forces the business to clear at least that much profit, and then it just quietly pays for itself.

People Buy From People. Right now Fireside’s edge is simple: Garrett and I do the support and build the product. If you send me the right request and I can knock it out fast, I’ll ship it before I even reply. Most customers aren’t technical (lots of Linux shows and religious orgs), and they value a real person who’ll hop on a Zoom and fix their DNS.

Marketing to the People You Already Have. Churn is around 2% and most of the focus has been telling existing customers we’re listening and shipping. Churn is a trailing indicator. By the time someone leaves, it’s too late to do anything about it. So we get ahead of it. The more aggressive growth (conferences, underserved niches) is the next wave.

Onboarding and Retention Are the Same Coin. Frictionless onboarding helps the self-serve people and the hand-held people at the same time. Every time you onboard someone manually, automate a little more of it so the next one is easier. I just rebuilt Flipper’s migration to be one click from the UI, the CLI, or the console. So slippery you slide right down the waterfall, and then you’re pulling out your credit card wondering what just happened.

A Scrappy, Opinionated APM. I’m building a lightweight APM (I called it Caboose on the show, it’s Flare now). The trick is that being opinionated makes it cheap. The expensive tools store everything so you can ask any question later. I’d rather pre-compute the answers to the questions you actually ask: count, sum, and error count per endpoint and job, the network breakdown (db, view, cache), and a handful of samples of slow requests. That solves 80 to 90% of performance problems for ten to fifty bucks a month instead of New Relic pricing that explodes the moment you add a teammate. This comes straight from my GitHub years doing analytics, statsd dashboards, and the Datadog migration.

Ops Without a UI. Honestly you barely need a dashboard. You want an API, a CLI, and skills or MCP so Claude can speak your language and pull the data. I did this with Flipper: dumped the gate data and 30 days of telemetry, asked Claude which flags I could delete, and cleared out about 15 stale flags and 600 lines of code in one pass. That’s the moment I knew I wanted the same thing for the APM. Knowing what’s happening in production and shipping safely matters more every month as people read less of the code themselves. GitHub Scientist style stuff, running two code paths and comparing them, is next on my radar.

We also got into Riverside versus Descript, why trying to do recording, editing, and hosting all at once turns into the PDA of old, being friends with your competitors, and my current obsession with Railway.

320 - John Nunemaker of Fireside.fm, Box Out Sports and Very Good Software - The Code with Jason PodcastIn this episode I talk with John Nunemaker about his journey with Ruby, acquiring Fireside.fm, and his ventures in software focused on podcast hosting and feature flag services. We also explore the potential impacts of AI in the development space and John’s vision for the future.Links:- Box Out Sports- Very Good Software- Flipper Cloud- Fireside.fm- Nonsense Monthlycodewithjason.com

Update 2026-10-01: I’ve stopped opening Flare’s web UI entirely and just ask my agent what’s slow. I talked about maybe shipping it with no UI at all on The Friday Deploy.

IndieRails Podcast: The Conductor

Thu, 19 Mar 2026 19:11:23 GMT

I hopped on IndieRails with Jess and Jeremy (again). We covered a lot of ground in about 90 minutes. Quick business catch up and then dove into how AI has changed pretty much everything about how I work.

Some of the highlights:

Business Updates. Flipper Cloud almost doubled revenue last year, with most of the growth in the last few months. No AI headwinds on docs or conversion. Fireside is stabilizing — we flattened churn and had our first three month stretch of even or growing customers since taking it over. Momentum, the coworking space I invested in, is filling up and becoming a real community in South Bend.

Following the Inspiration. I’m a mood person. I follow the energy. Having multiple products at different stages (five, six, and seven figures) means there’s always something that matches whatever I’m feeling that day. I’ve spent 20 years intentionally building toward that flexibility.

Support-Driven Development. With Fireside, I’m close to the customer again. Someone asks for a responsive player, I build one from scratch in three days. Someone wants playlists, done. Someone wants custom colors saved, done in an hour. They’re blown away because the product had been dormant. That feedback loop is addicting.

The Company Brain. For Box Out, I’m building an internal AI system using LibreChat with MCPs for our read replica database, Stripe, and a custom internal API. The goal is letting our small team query business data naturally — hydrate conference attendee lists, look up support patterns, pull subscriber counts. Eventually I’ll wire in Metabase too for the verified reports.

Working Styles. Jeremy, Jess, and I got into how different developers use AI differently. Garrett goes heavy on docs and specs and skills. I go vanilla — whisper flow, let it roll, see what happens. Both approaches work. A lion doesn’t concern himself with tokens.

The Arbitrage. There’s a window right now where you can get significantly more done. Not just a little more — I’d say I’m working 1.3-1.5x the hours but shipping 10x. That won’t last forever, but right now the gap between people using these tools and people who aren’t is massive. And we’re still just the nerds. Most people haven’t even tried a chatbot yet.

What’s Next. I think the AI era means more people shipping more code, which means more demand for developer tools — monitoring, debugging, feature flags, experiment frameworks. That’s why I’m building an APM tool and planning to build something like GitHub Scientist next. The incumbents have no incentive for you to send less data. I think there’s room for opinionated, affordable, AI-friendly developer tools.

Conductor in the Web. What I really want is my dev environment on a server somewhere, always on, accessible from my phone. Spin up workspaces, prompt the next thing, check in from the couch or car line. Someone’s going to solve this well in the next couple months. I’d pay as much as I do for Claude for that solution.

We also got into the health and sustainability of all this, the farming lifestyle analogy (Jeremy and I both grew up in farm country), consulting economics in the AI era, and whether developers should be pushing harder toward ownership.

Listen here.

Update: Codex remote access turned out to be most of what I wanted. My already set up Mac sits on my desk and I fire off commands from my phone, even from a camping chair. I talked about it on YAGNI.

Rails Business Podcast (again)

Thu, 05 Mar 2026 20:14:06 GMT

I joined Brendan Buckingham and Ryan Frisch on the Rails Business Podcast to talk about how AI has changed my day-to-day as a developer.

John Nunemaker on AI Development - Rails BusinessJohn Nunemaker returns to discuss how fast AI tooling has changed and argues tech leaders should adopt Claude Max (defaulting to Opus), set up agent-friendly local environments, and roll that out to their teams. He shares how his company built an…railsbusiness.com

Here are the highlights:

Your job as a tech leader is to go first. Get Claude Code with Opus, set up your local dev environment to be agent-friendly, then do the same for everyone on your team. I told everyone to get the $100 Max plan and offered to pay for it myself if they didn’t think it was worth it. No one’s taken me up on that.
“Brain,” an AI-in-a-box for the company. I built an internal tool on a cheap Hetzner server using LibreChat, Postgres MCP (read-only replica), Stripe MCP, and a custom support MCP. Non-technical teammates can now ask natural language questions about customers, support trends, and revenue data without going through me. Secured it all behind Tailscale.
The support insights were eye-opening. By slurping all our Crisp support conversations into a database and hooking it up as an MCP, I could ask things like “summarize the last week of support requests” and “what’s the tone of our support person?” and get real answers. Next step is cron jobs that automatically post weekly summaries to Slack.
Claude as a code review spin cycle. Team members now run Claude review locally, fix issues, then run @claude review on the GitHub PR before requesting human review. By the time it gets to me, it’s usually ready to merge. This solved the bottleneck of everyone suddenly producing several PRs a day.
Conductor changed the game for parallel work. It manages isolated worktrees with separate databases, ports, and sessions. I can work on 3-5 things simultaneously, like a feature, a bug from Honeybadger, a support request, each in its own workspace. Setup and teardown scripts handle the isolation (fewer than 100 lines of code per app).
People who couldn’t write Rails before now can. Phillip, who we brought on for React/HTML, is now consistently making solid Rails PRs. Claude bridges the gap. The first PR needed some guidance on resiliency patterns, but after that, the spin cycle workflow handles it.
Caddy for local HTTPS and custom domains. Drop it in your Procfile, point wildcard subdomains at it, and you get HTTPS locally with custom domain support. Solved a bunch of pain around cookies, CORS, and multi-workspace development.
Stay bullish. Software engineering jobs are reportedly up about 4.5% month over month. There’s an arbitrage window right now for teams that adopt these tools early. Don’t get behind. That’s the worst place to be.

Conducting Rails

Fri, 30 Jan 2026 18:01:29 GMT

In short

Conductor creates isolated workspaces for running multiple coding-agent sessions in parallel. To make that model reliable with Rails:

Copy required gitignored files into each workspace.
Derive ports, hosts, cookies, and generated URLs from CONDUCTOR_PORT.
Give every workspace its own development and test databases.
Automate setup, startup, and teardown scripts.
Account for shared services such as S3 and make each browser tab identifiable.

I’ve been using @conductor_build heavily and it’s completely changed how I ship Ruby on Rails code when working with Claude models.

The multi-workspace, multi-process model feels unusual at first compared to a single editor flow, but once you handle the Rails-specific quirks, your ability to work in parallel and ship faster skyrockets.

Here are the key practical steps and fixes I’ve found essential for getting a Rails app running reliably across multiple Conductor workspaces. I’ll try to keep this up to date as I find new things.

Copy essential gitignore’d files

Anything in .gitignore (credentials, .env.local, custom config files, active storage files in tmp/ etc.) won’t copy automatically. Manually cp these from your main CONDUCTOR_ROOT project directory into each workspace directory during initial setup. This keeps isolation clean without git
pollution.

Drive everything through `CONDUCTOR_PORT`

Conductor assigns dynamic ports—make your app fully aware of them:

Prefer ENV['CONDUCTOR_PORT'] with a fallback (e.g., 3000).
Update Action Mailer default_url_options, controller/view host generation, and any internal URL building to use the current host + port.
Scope sessions and cookies by host + port to prevent collisions across workspaces.
A solid starting point for host and port handling is in in this Gist.

Isolate databases for parallel execution

Shared test databases cause lock errors when running specs/tests concurrently across workspaces. Solution:

Create a per-workspace test database (suffix by workspace ID, CONDUCTOR_PORT, or Rails test env number).
Archive/drop the DB on workspace close.
For dev, if you create new dbs, seed them in the conductor setup.

Use setup, run, and teardown scripts

Conductor supports these hooks natively. Automate workspace preparation (DB setup, seeding, file copying), server startup, and cleanup. This makes spinning up and tearing down consistent, repeatable, and fast.

Create bin/conductor-setup (or just mod bin/setup to work differently when conductor ENV vars are present) and bin/conductor-teardown (for when archive happens). run can just be bin/dev or whatever you use.

CORS (direct uploads)

One other issue is direct uploads to S3 and similar services. You’ll want to be sure to use a dev bucket that allows any host/port.

aws s3api put-bucket-cors --bucket your-bucket-dev --region us-east-1 --cors-configuration '{
  "CORSRules": [
    {
      "AllowedHeaders": ["*"],
      "AllowedMethods": ["GET", "POST", "PUT", "HEAD"],
      "AllowedOrigins": ["*"],
      "MaxAgeSeconds": 3000
    }
  ]
}'

Rename browser tabs

Last but not least, rename your browser tabs. Trying to remember which port goes to which workspace is annoying. Just rename it once you open it to whatever the workspace is and you’ll be golden.

The Shift

The mindset shift to multiple concurrent processes and workspaces is the biggest hurdle. Once it clicks and your app behaves correctly across them, the productivity gain is massive. If you run into Rails-specific issues (subdomains, shared resources, etc.), the fixes are usually straightforward. Just ask claude/conductor how to fix them by updating the bin scripts I mentioned above.

Conductor + Claude Opus has mostly replaced my editor for day-to-day work. I only fall back to a traditional editor for quick muscle-memory tasks.
The GitHub flow of Create PR > Run CI > Fix CI Failures > Merge is SICK.
Every support request or thought that pops in my head becomes a workspace.
Heavy usage quickly justifies upgrading your Claude plan if you’re on a lighter tier. The combination of claude + conductor unlocks a lotta throughput.

If you’re building with Rails and leaning on Claude heavily, Conductor is worth the initial setup effort. The payoff in shipping speed is real.

Always happy to brainstorm fixes for any Rails gotchas you hit—just reach out.

Rooted & Reaching Podcast Interview

Fri, 23 Jan 2026 19:33:23 GMT

I recently sat down with Marty Mechtenberg on the Rooted and Reaching podcast to talk about my entrepreneurial journey, from struggling through my first programming class at Bethel to building multiple SaaS businesses while staying rooted in the South Bend area.

The Early Days: Learning to Code (the Hard Way)

I wasn’t a natural programmer. In my sophomore year at Bethel, I was pulling a D in my programming class while my future business partner Steve would walk in, hand in his homework, and leave. I spent hours in office hours, terrified of failure after a lifetime of straight A’s. But that struggle taught me something important: once I learned something the hard way, it stuck.

What really hooked me was the internet. The moment I could make something and have my mom see it by typing a URL into her browser, that was magic. That’s when programming stopped being abstract loops on a screen and became something I couldn’t stop doing.

After Notre Dame, I joined my friend Steve Smith at Ordered List, a small agency. We had a simple philosophy: talk about everything we built. We blogged about our process, spoke at conferences, and contributed to open source. We weren’t trying to be clever about marketing, it was just what we knew how to do.

That openness led to opportunities we never expected. Speaking at a Ruby conference in New Orleans, I reconnected with a friend who had started GitHub. One conversation led to another, and eventually GitHub acquired our five-person team in 2011.

The GitHub Years (and Why I Left)

GitHub was an incredible ride—from 45 employees to over a thousand in just four years. But as the company grew, so did the layers between me and any real decision-making power. By 2016-17, I was seven layers deep and itching to get back to building things my own way.

When Microsoft acquired GitHub in 2019, I took my exit. I needed to reclaim my indie spirit.

Building for Flexibility, Not Fortune

Today I run multiple products: Box Out Sports (sports graphics for schools), Flipper (feature flags for developers), and Fireside (podcast hosting). The common thread? I’ve always optimized for flexibility over maximum revenue.

I watched my dad work 90-hour weeks on the farm. I wanted the freedom to take a seven-week camping trip in the summer.

My advice for aspiring entrepreneurs: work your tail off in your 20s across different environments. Figure out what you actually like. Then optimize for the life you want, not just the biggest paycheck.

Why South Bend?

People ask why I didn’t move to San Francisco. The answer is simple: South Bend has everything I need. Good restaurants, Notre Dame athletics, a reasonable cost of living, no brutal traffic. It’s big enough to have what matters, small enough to avoid what doesn’t.

Plus, there’s something special here I didn’t expect to find: South Bend had its own watch company in the early 1900s, making precision pocket watches for the railroad industry. I’ve become obsessed with finding and restoring these watches—physical artifacts I can pass down to my kids, unlike software that rots in three years without constant care.

The AI Era

I’m not worried about AI taking over. I’m obsessed with it. It’s made me multilingual as a programmer. I can now contribute to Go projects despite being a Ruby developer for 20 years. The fundamentals I learned the hard way? They translate perfectly to telling Claude or ChatGPT exactly what I need.

The key is knowing what to ask for. Twenty years of programming principles don’t disappear, they become the foundation for working with AI effectively.

Hope you enjoy!

What makes you different

Mon, 13 Oct 2025 14:39:27 GMT

Something that’s been on my mind lately: Why is a customer going to choose my product? There’s tens to hundreds or even thousands (looking at you CRM’s) of every app for every problem. Why would someone choose mine?

Price? I’m a firm believer in charging a price that works for the customer and for you. Competing on price is a race to the bottom. If this is where you are at, you’ve already lost.

Features? Maybe but that’s a grind and a bit whack-a-mole. Having all the features someone could ever want waters down a product. Honestly, it makes products confusing. How do you build work flow and create value for the customer when the customer is anyone and the work flow is anything?

Something else? I’m becoming a bit obsessed with what makes you different. People remember different. And when someone gets out their card to buy something, you want them to remember you.

Our brains love to live on autopilot in a sea of sameness. This makes us hyper-sensitive to different. Even if that weren’t true, different is great because it makes comparison difficult. Instead of granny smith verse golden delicious, it’s apples and oranges.

The Hot Dog

In Unreasonable Hospitality, Will Guidara recounts the story of one particular table of diners at Eleven Madison. They were foodies in New York from overseas to enjoy the best restaurants.

They’d probably had several amazing experiences. But one of them mentioned they were bummed they didn’t get a new york hot dog. This was their last night in the city, so Will ran to the nearest hot dog cart, got a dog and convinced his chef to serve it to them.

Of all the places they dined, who do you think they remembered? Which story do you think they told people over and over? The hot dog.

Different is remembered. Different is shared. It’s better than being better. And that’s why I can’t stop thinking about what makes my products different.

An Example

Let’s talk about Box Out for a moment as a practical example.

Our competition focuses on infinite customization. Move this logo wherever you want or make it bigger. Change the font or text size. Drag this. Drop that. All of them just re-create Photoshop in the browser with a bunch of stock templates to choose from. Heck, that is all canva is.

We do the opposite. We focus on speed (time to social timeline) and brand (delegate to students/interns but retain quality). How fast can we help you make a graphic to share with your followers (and then move on with your life).

Don’t move things around, it’s wasting time.
Lock down colors, fonts and templates.
Don’t resize logos or text.

We’re different. Those differences create constraints that actually guide us to build a better product. Sure, we’ve been tempted to build drag and drop, but that would be a disservice to our customers. Their time is better spent on other things.

Trade offs

Everything is trade offs. Things like the list below would be dramatically harder or impossible if we allowed that.

Multi-format. Different platforms prefer different sized graphics. We handle that for you. X gets widescreen, IG 4:5 (or now 3:4), Story format. Fill out your data once and hit share. Don’t duplicate and resize and move stuff around.
Suggestions. Not sure what to say? Hit a button and get 5 options with different tones that smell quite similar to your previous shares. Of course they are based on the graphic you are attaching to the share.
Built-ins. Need to crop an image or trim a video? No problem. Do it right in the browser, right from the graphic you are creating. No need to leave the browser. We’ll even remove the background for a stunning PNG cut out on many graphics. Not ready to share yet? Schedule it for later.
Autofill. We autofill fields for the graphic based on what you’ve previously used, upcoming events, your linked brand information, opponents linked brand information, live stats, etc. Autofill means fewer fields to fill out.
Speed. We just spent months decreasing average graphic render time from 2.9 to 1.1 seconds. Rendering is so fast now that it feels live.

For Box Out, it’s easy to define and see the value those differences create for us (and our customers). Now it’s time to think what those differences are and will be for Fireside and Flipper…

Self-Made is a Myth Podcast

Wed, 01 Oct 2025 15:19:04 GMT

I’m never one to turn down being on a podcast, especially since acquiring Fireside.fm, a podcast host. So yesterday, I hopped on a call with Tim Campsall to chat about running Box Out and Very Good. And the crazy thing is it’s already out on Youtube. I wasn’t in my home office so my background was bleak and my audio was subpar but still a great conversation.

Highlights

Shortest path between builders and users is critical.
Hire “batteries included” people who are self-driven.
I’m not really good at anything specific. I’m just good at being glue.
Measure progress (time tracking) and celebrate wins to avoid burnout.
Design products to save people time. Design your business to free your own time.
People buy from people. My dream as a developer is to build a good product and never talk to anyone, but it just doesn’t work that way.

Giant Robots

Thu, 29 May 2025 14:19:23 GMT

A few weeks back I joined Chad on his Giant Robots podcast to talk Ruby, Rails and a bit of business – including our acquisition of Fireside last year. The episode just went live and I hope you enjoy it.

Fun fact: their podcast is actually hosted on Fireside – inception! You can listen wherever you consume podcasts or on Fireside (below) or youtube.

Rails Business Podcast

Tue, 15 Apr 2025 20:28:09 GMT

I had a nice chat with Brendan and Ryan on the Rails Business podcast a few weeks ago and now its live! Search for “Rails Business” in your favorite podcast app or you can listen at the following link:

John Nunemaker - Rails BusinessIn this episode, Brendan and Ryan welcome John Nunemaker.  John is a prominent figure in the Ruby community and, shares his journey into Ruby on Rails, his career evolution, and his unique approach to managing multiple projects simultaneously…railsbusiness.com

If you want the tldr, we cover:

my journey into Ruby and Rails
my current projects and Ruby usage
the role of AI in my dev process
how to balance multiple projects
time tracking and productivity
consistency across projects
the origin and success of Box Out
future plans

Ruby on Rails Podcast: Taking over Fireside.fm

Wed, 22 Jan 2025 21:13:43 GMT

I was stoked when I discovered that the Ruby on Rails podcast is hosted on our platform – fireside.fm. So I reached out to Elise for feedback and to volunteer Garrett and I for an episode.

We recorded last week and its already live today. Our chat covered taking over an outdated Rails app and all the progress we’ve made modernizing it the past few months. We even threw in a few stories of battle scars earned.

Enjoy!

P.S. It’s been 5 years since I was last on the rails pod (Brittany Martin was the host).

Update 2026-10-01: Two years in, almost nothing from the outdated app we took over is left. Garrett and I told the rest of the story, including Postgres 9.5 to 18 in one hop, in episode one of our new podcast, The Friday Deploy.

Episode #4

Thu, 09 Jan 2025 21:47:52 GMT

It’s out and it’s stout. Actually, I don’t know if it’s stout or not. I just like to rhyme (all the time).

My 3 Fav Quotes

“What if instead of discounts, we focused on lowering the risk for customers to try podcasting?” – Garrett

“You don’t have to go crazy and work a ton. You can you can achieve great success by turning a few levers. But sometimes it just takes a lot of work to figure out what those levers are.” – John

“I’m just thinking about swag, but that’s a discussion from another day.” – Kris

Black Friday Reflections and New Year OpportunitiesI was hoping to get this out last year, but holidays got in the way of that (in a good way). So here is the last episode recorded in 2024, fresh for you to enjoy in 2025. * Black Friday Reflections and Trends * Rethinking Sales Strategies for Software * Technical Upgrades andblog.fireside.fm

Big shoutout to Riverside. We use them to record and edit this. And I’ve found it pretty fun the past couple times.

Episode #3

Tue, 31 Dec 2024 19:33:13 GMT

For those that haven’t subscribed to the fireside blog or the podcast, I figured I’d update here as well. We released episode #3 on Mastering Prioritization in SaaS last week. Give it a listen and subscribe in your favorite podcast app. At some point I’ll get too lazy to post here too. 😄

One of my favorite parts was the segment on time tracking, something that I’ve found useful of late.

Episode #2

Tue, 17 Dec 2024 13:41:23 GMT

Episode #1 went out last Thursday. Now here we are on Tuesday and ANOTHER EPISODE FOR YOU. I know right?! Christmas came early this year.

On today’s episode, we hit on a few topics:

🙋 Customer feedback.
😖 Podcasting pains.
🆕 Future features.
🏆 Recent wins.

Just hit play… you know you want to. And then be sure to subscribe.

In the interest of getting better, we’re improving something each episode. Today’s improvement was a wee bit of intro/outro music.

Episode #1

Thu, 12 Dec 2024 15:05:32 GMT

We did it! The Fireside crew went through the entire process of setting up a podcast and recording our first episodes.

#1 is live wherever you enjoy podcasts (probably).

I never would have guessed how tedious it would be to get your first episode out the door. Now I have a ton of respect for our customers, especially our non-technical ones, who have made it through this gauntlet.

So much information to fill out! I’m looking forward to getting this process locked down so new episodes will be much easier. Also, planning to start paying for an editor. 🤣

We set the quality bar very low for this. We know we’ll get better with each episode but we had to start somewhere. Enjoy!

And be sure to subscribe!

Shrinking a Postgres Table

Thu, 28 Nov 2024 14:10:17 GMT

In short

I shrank a 57 GB PostgreSQL table by cloning its structure, copying only the rows worth keeping, briefly renaming the old and new tables, and then dropping the original. The swap took about 10 seconds and reduced server disk use from 87% to 53%.

Identify the table and rows consuming the space.
Create a replacement with CREATE TABLE ... (LIKE ... INCLUDING ALL).
Copy only the rows you need into the replacement.
Rename the old and new tables during a short maintenance window.
Validate the replacement, then drop the old table to reclaim disk space.

This was a calculated tradeoff for this application. Before using the technique, verify your constraints, indexes, sequences, dependencies, write traffic, and recovery plan against your own schema.

Ok folks, this is kind of a weird one. I’m going to put it in the “you won’t ever need this, but if you do, you are going to be glad I wrote this up for ya” category.

As you may or may not know, I recently acquired fireside.fm, an awesome podcast host. While investigating a slow query, I noticed that the database servers were at 87% disk space use.

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       158G  129G   21G  87% /

I typically use a managed Postgres, which makes it real obvious when you are starting to use a lot of disk space and easy to fix. But this is self-managed Postgres on Linode.

Servers don’t like to run out of disk space (or even get close to running out).

What is taking up the space?

So I started up a casual chat with GitHub’s Copilot. You know, the typical, “how are you?”, “oh I’m fine, you?”, “yeah, same”, “do you like long walks on the beach?”, “yeah, my database is about to fall over too”.

I asked Copilot how I could quickly get the size of the database:

SELECT pg_size_pretty(pg_database_size(current_database())) AS database_size;
-- 114 GB

Unfortunately, my database was the problem, not some rogue log file or backup retention policy.

My next question was which table is taking up all the space:

SELECT 
    table_name, 
    pg_size_pretty(pg_total_relation_size(table_name)) AS total_size
FROM 
    information_schema.tables
WHERE 
    table_schema = 'public'
ORDER BY 
    pg_total_relation_size(table_name) DESC;

The usual suspects filled up the top 10 (analytics/metrics):

            table_name             | total_size 
-----------------------------------+------------
 downloads                         | 57 GB
 downloads_archive                 | 30 GB
 day_downloads                     | 12 GB
 location_downloads                | 6235 MB
 metrics                           | 3537 MB
 user_agent_downloads              | 2145 MB
 spotify_day_downloads             | 2072 MB

downloads seemed the largest so I started there. I wasn’t entirely sure how the table was used (again I’m new to this app). So I poked around for min and max created_at times. To my surprise, there were rows going back to 2021.

Why is the downloads table large?

The downloads table seemed to be a record of all the raw downloads before they are aggregated into tables more efficient for querying in a web request. As downloads are processed, they are deleted from the table.

The problem was many records (10’s of thousands an hour) were not being processed and thus not being deleted. Those downloads seemed to be for episodes that no longer exist for various reasons.

Over the course of many years, this added up to many 10’s of millions of rows and 35% of the disk space. I sliced and diced several queries and determined that every download older than a few hours was effectively bad data and not processable.

Now I knew what my issue was, but I wasn’t sure about the best fix.

How to shrink the table with a table swap

If you don’t know this already, Copilot is great for brainstorming stuff like this. Talk human to it and it’ll throw ideas back to you.

Copilot really wanted me to delete the rows in batches of 1-10k and then vacuum at the end. But not vacuum full because that would lock the database and bring down the house.

I ran the first query to delete 1k records:

WITH rows_to_delete AS (
    SELECT id
    FROM downloads
    WHERE created_at < '2022-01-01'
    LIMIT 1000
)
DELETE FROM downloads
WHERE id IN (SELECT id FROM rows_to_delete);

But it took like 20 seconds.

I wasn’t going to sit around and run this 30 - 50 thousand more times.

I also didn’t really feel like making a background job to handle this for me.

Additionally, copilot wasn’t sure how much space would actually be freed up by a vacuum (as compared to a vacuum full).

The easiest, fastest and most guaranteed way to free up space for a table is to drop it. But I did want some data out of it. That’s when I remembered table swapping.

I asked Copilot for the best way to clone the downloads table:

CREATE TABLE downloads_new (LIKE downloads INCLUDING ALL);

🆒

And how do I insert only the rows I need, those that are downloads for episodes that exist:

INSERT INTO downloads_new 
  SELECT d.* FROM downloads d 
  INNER JOIN episodes e ON e.token = d.episode_token 
  WHERE date_trunc('day', d.created_at) >= '2024-11-27';

😎

And lastly, how do I swap the tables:

ALTER TABLE downloads RENAME TO downloads_old;
ALTER TABLE downloads_new RENAME TO downloads;

Sure, I could have looked these up in the Postgres docs or on Stack Overflow, but the ability to paste in your schema for your table and say in English what you want to do and get exact commands to copy is just amazing.

The only bit left was to drop the original table with all the junk data:

DROP TABLE downloads_old;

At this point, I had a brand, spanking new downloads table with only 30-40k records (past hour or so of downloads) and a whole lot more disk space:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       158G   80G   71G  53% /

The best part is it took about 10 seconds to run the queries and I lost, at most, if anything, a few seconds of data during the data dump and table rename.

A worthy trade off compared to hours of coding and babysitting.

Brainstorming with Real People

Now, it’s worth mentioning that I wasn’t entirely sure if this was going to get me the result I hoped for (no downtime, low effort, and freed up space).

So first, I dropped into my handy dandy, top secret slack of battle scarred programmers who are smarter than me.

Akin to Copilot, I posed the same question and I got a variety of other options. I felt good about all of them, but none could compare (IMO) with the simplicity of the table swap.

No one seemed overly scared that the table swap wouldn’t work. And I got a yes from two people who thought it would be easiest. That was enough to give me the confidence to try it first.

Cheers to top secret slacks with smart people and AI chat bots! 🍻

So that’s how I spent my Thanksgiving morning!

And, honestly, I’m good with that. Feeling thankful even.

I learned something new. I saved my database.

And now I’m going to eat some great food and hang out with family sans a low undercurrent of stress wondering if my poor little database has crept from 87% to 88% disk usage or even higher!

John Nunemaker

The Friday Deploy: Your PR Shouldn't Make Your Stomach Hurt

Put an End on the Review

Quiet Support Isn’t Proof

Two Flags, Two Decisions

More of the Fun Stuff

Don't Make a Human Do What AI Is Amazing At

What Nunebot Is

Why I Built It

Step One: Give It All the Context

Step Two: Decide What to Do

Taste

Step Three: Build It, Shave It, Try to Break It

Step Four: Prove It

Step Five: Let It Rip

Guardrails

The Numbers

What’s Next

The Friday Deploy: Changing the Wheels While the Car Is Moving

Episode 1: Changing the Wheels While the Car Is Moving

YAGNI: Camping Chair Development

The Hallway Track: Why AI Rewards People Who Already Have Taste

Code with Jason: People Buy From People

IndieRails Podcast: The Conductor

Rails Business Podcast (again)

Conducting Rails

In short

Copy essential gitignore’d files

Drive everything through CONDUCTOR_PORT

Isolate databases for parallel execution

Use setup, run, and teardown scripts

CORS (direct uploads)

Rename browser tabs

The Shift

Rooted & Reaching Podcast Interview

The Early Days: Learning to Code (the Hard Way)

Ordered List and the Power of Sharing

The GitHub Years (and Why I Left)

Building for Flexibility, Not Fortune

Why South Bend?

The AI Era

What makes you different

The Hot Dog

An Example

Trade offs

Self-Made is a Myth Podcast

Highlights

Giant Robots

Rails Business Podcast

Ruby on Rails Podcast: Taking over Fireside.fm

Episode #4

My 3 Fav Quotes

Episode #3

Episode #2

Episode #1

Shrinking a Postgres Table

In short

What is taking up the space?

Why is the downloads table large?

How to shrink the table with a table swap

Brainstorming with Real People

Drive everything through `CONDUCTOR_PORT`