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.

John Nunemaker on AI Development - Rails Business

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

Buzzsprout

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.

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.

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.

Ordered List and the Power of Sharing

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!

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

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.

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

John Nunemaker - Rails Business

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

Buzzsprout

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

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

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 Opportunities

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

Fireside.fm BlogJohn Nunemaker

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

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

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.

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

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.

Brainstorming with Copilot

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!

FounderQuest | Acquiring Fireside with John Nunemaker

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

FounderQuest

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

• Code and the Coding Coders who Code it
• Changelog: The moneyball approach