The Friday Deploy: Changing the Wheels While the Car Is Moving
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.