John Nunemaker

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!

Founder Quest: Acquiring Fireside

Fri, 11 Oct 2024 15:26:40 GMT

Last, but not least for this week, I was on Founder Quest. I’m doing my best third wheel impression over there and appreciate that Ben and Josh haven’t kicked me off yet. We talked about a lot of things but mostly focused on the fireside acquisition.

FounderQuest | Acquiring Fireside with John NunemakerJosh and Ben talk with John about his recent acquisition of Fireside, covering the finances, pitfalls avoided, and more acquisition tips.https://www.johnnunemaker.com/acquiring-fireside/https://www…founderquestpodcast.com

If you missed the other podcasts this week, here you go:

The Moneyball approach

Thu, 10 Oct 2024 18:46:49 GMT

I joined Adam and Jerod to share my new thesis for acquiring Rails based SaaS apps. The conversation was great! This new moneyball approach (dubbed so by Jess) has been swimming around in my head for a few months now. So it’s great to talk about it in public finally.

Changelog Interviews 612: The Moneyball approach – Listen on Changelog.com

If you like the episode, give 5 Businesses Acquired with a Long-Term Hold Model a listen too. Great stuff by someone with a lot more experience than me.

If you missed the other podcasts this week, here you go:

John Nunemaker

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

Founder Quest: Acquiring Fireside

The Moneyball approach

Drive everything through `CONDUCTOR_PORT`