Podcast episode outline with timestamps and talking points that sounds unrehearsed

# Podcast Episode Outline **Show:** The Build Lab **Episode:** "Why Your Side Project Needs Worse Technology" **Format:** Solo host with call-in segment **Target length:** 45 minutes **Listener persona:** Mid-career developers (28-40) who have side projects that never ship --- ## PRE-SHOW NOTES **Energy level:** Start at 6/10 (reflective, almost confessional), build to 8/10 by the main segment. This episode is about vulnerability — you're admitting YOUR mistakes first before giving advice. **Mental frame:** Think about the last side project you abandoned. Remember the exact moment you decided to add that unnecessary feature or switch frameworks. That feeling of "ugh, I did it again" is the emotion you want to channel. **Key phrase to internalize before recording:** "Done is better than perfect, and shipped is better than done." --- ## COLD OPEN / TEASER (selected from main content) **Suggested clip (from ~18:00 mark):** "I had eleven side projects in three years. Eleven. You know how many shipped? One. And it was the one I built with the most boring technology imaginable. No React, no Kubernetes, no microservices. Just PHP and a shared hosting account. And it made $4,000 in its first month." [HOST NOTE: This clip works because it has a specific number (11), a confession, and a surprising punchline. Drop it in with no introduction — just the raw audio, then your intro music.] --- ## FULL EPISODE BREAKDOWN ### 0:00-0:45 — Teaser Clip Drop the cold open clip. No context. Let it sit for a beat after the clip ends. ### 0:45-2:00 — Intro + Episode Setup **Talking points:** - Standard show intro, keep it tight - "Today we're talking about something that's going to make a lot of you uncomfortable" - Frame the episode: "This is about why the technology you're choosing for your side projects is the reason they never ship" - Set expectations: "I'm going to share my own graveyard of projects, then give you a framework that actually works" [HOST NOTE: Don't rush the setup. Let the premise breathe. Your audience is already hooked from the teaser — they want the story, not the lesson yet.] **Transition:** "But first, let me tell you about the project that started all of this." --- ### 2:00-8:30 — Segment 1: The Side Project Graveyard (6.5 min) **Talking points:** - Walk through 3-4 of your abandoned side projects chronologically - Project 1: The task management app built with a custom GraphQL API ("because REST was too basic") - Project 2: The recipe sharing site with real-time collaboration ("because Google Docs exists and somehow I thought I needed WebSockets for recipes") - Project 3: The bookmark manager with AI categorization ("spent 3 months on the ML pipeline, never built the bookmarking part") - For each one, identify the EXACT moment scope creep killed it - Be specific about time wasted — "I spent 47 hours setting up a CI/CD pipeline for an app that had zero users" - The common pattern: choosing technology BEFORE defining the problem [HOST NOTE: This segment is storytelling. Use self-deprecating humor but don't make it a bit — the audience should relate, not laugh at you. Pause after each project story to let it land. The audience is mentally cataloging their OWN graveyards right now.] **Listener engagement moment:** "I want you to think about your own graveyard right now. How many abandoned repos do you have? DM me on Twitter with just the number. No context. Just the number." **Transition:** "So that was three years and eleven projects. Then something changed." --- ### 8:30-10:00 — Ad Read #1 (1.5 min) **Natural transition:** "Before I tell you what changed, quick shoutout to [sponsor]..." [HOST NOTE: This is the perfect ad break placement. The audience just heard the story of failure and you promised the turning point. They're NOT leaving during this ad. Keep the ad read conversational — if it's a dev tool, connect it to the episode theme: "Speaking of tools that actually help you ship..."] **Post-ad transition:** "Okay, so — the project that actually shipped." --- ### 10:00-18:00 — Segment 2: The Boring Technology Thesis (8 min) **Talking points:** - Tell the story of the ONE project that shipped - What it was (simple SaaS tool — be specific) - The "boring" tech stack: PHP, MySQL, shared hosting, jQuery - Why you chose it: "I was so exhausted from framework fatigue that I just picked the thing I could move fastest with" - Timeline: idea to launch in 3 weeks (vs. 3+ months on abandoned projects) - Results: first paying customers within a month - Introduce the "Boring Technology Framework": 1. **Define the outcome first** — what does the user need to DO? 2. **Pick the tech you're fastest with**, not the tech you want to learn 3. **Set a 30-day ship deadline** — if it's not live in 30 days, the tech is too complex 4. **No infrastructure until you have users** — shared hosting, SQLite, flat files are FINE 5. **The upgrade trigger** — only add complexity when a SPECIFIC problem forces you to - Reference Dan McKinley's "Choose Boring Technology" essay - Key argument: "Every new technology you introduce is a token you're spending from a very limited budget. Side projects have almost no tokens." [HOST NOTE: This is the MEAT of the episode. Slow down here. The framework is the part people will screenshot and share. Number each point clearly. Repeat the framework name twice so people remember it. When you say "shared hosting and jQuery," lean into it — say it like you're confessing something embarrassing, then own it.] **Transition:** "Now I know some of you are already composing angry tweets. 'But Boring Technology won't scale!' Let me address that." --- ### 18:00-25:00 — Segment 3: Objection Handling (7 min) **Talking points:** - Objection 1: "But it won't scale" - Counter: "You don't have a scaling problem. You have a shipping problem. Scale is a luxury problem — earn it first." - Example: Craigslist still runs on Perl. PlentyOfFish ran on one server until it had 30M users. - Objection 2: "But I want to learn new tech" - Counter: "Great — learn it at your day job, or in a sandbox project with no shipping pressure. Side projects with revenue goals need proven tools." - The distinction between learning projects and shipping projects - Objection 3: "But modern tools are actually faster" - Counter: "Faster to START, not faster to SHIP. Next.js has 47 config options before you write a line of business logic. PHP has zero." - Nuance: "I'm not anti-modern tech. I'm anti-modern tech for the FIRST VERSION of a side project." - Objection 4: "But my project needs [specific complex thing]" - Counter: "No it doesn't. Not yet. Ship the 80% version and see if anyone cares before building the 20% that needs complex infrastructure." [HOST NOTE: This segment should feel like a conversation with a skeptical friend. Don't be preachy. Acknowledge that these are VALID concerns, then reframe them. Use phrases like "I hear you" and "that's fair" before each counter.] --- ### 25:00-26:30 — Listener Call-In / Voice Message (1.5 min) **Setup:** "We got some voicemails this week from listeners who actually applied the boring technology approach. Let's hear from [name]..." [HOST NOTE: Play 1-2 pre-screened listener voice messages. Pick ones with specific results ("I shipped my project in 2 weeks using..."). React authentically — don't script your response. A genuine "oh that's awesome" is better than a polished follow-up.] --- ### 26:30-28:00 — Ad Read #2 (1.5 min) **Natural transition:** "Love hearing those wins. Speaking of tools that help you ship faster..." --- ### 28:00-36:00 — Segment 4: The Practical Playbook (8 min) **Talking points:** - The "Side Project Launch Stack" — a decision tree for choosing tech: - Need a web app? → Start with the framework you've used the most, even if it's "outdated" - Need a database? → SQLite unless you have a SPECIFIC reason for Postgres - Need hosting? → Railway, Render, or even shared hosting. No Kubernetes, no Docker (yet) - Need auth? → NextAuth, Passport, or even just session cookies. No Auth0, no Clerk (yet) - Need payments? → Stripe Checkout (hosted page). No custom payment flows - The "30-day challenge" format: - Week 1: Core feature only (the ONE thing your app does) - Week 2: Make it not ugly (but don't make it beautiful) - Week 3: Add payments and deploy - Week 4: Launch, collect feedback, decide if you continue - Real examples of successful "boring tech" launches: - Nomad List: PHP + jQuery (made $1M+) - Carrd: one developer, simple stack (makes $1M/year) - Pieter Levels' approach in general [HOST NOTE: Be prescriptive here. Don't say "consider" — say "use this." Your audience is tired of options. They want someone to tell them what to do. The decision tree should feel like a flowchart they can follow with their eyes closed.] **Listener engagement:** "Screenshot this decision tree and save it. Next time you start a side project, pull it up before you touch a terminal." --- ### 36:00-40:00 — Segment 5: When TO Use Fancy Tech (4 min) **Talking points:** - Acknowledge: "I've spent 35 minutes telling you to use boring tech. Let me tell you when to ignore everything I just said." - The upgrade triggers: - You have 1000+ users and a SPECIFIC performance problem - Your current tech literally cannot do something you need (real-time, ML, etc.) - You've validated the product and are ready to invest in the platform - You're migrating from side project to full-time business - "The point isn't to NEVER use modern tech. It's to earn the right to use it by shipping first." [HOST NOTE: This segment prevents the episode from feeling dogmatic. You want listeners to leave with nuance, not just "old tech good, new tech bad." End on a balanced note.] **Transition:** "Alright, let me wrap this up." --- ### 40:00-43:30 — Wrap-Up + Key Takeaways (3.5 min) **Talking points:** - Recap the three main ideas: 1. Most side projects fail because of technology choices, not ideas 2. The Boring Technology Framework: define outcome → pick fastest tool → ship in 30 days 3. Earn the right to add complexity by getting users first - "My challenge to you: take your current stalled side project, strip out every piece of technology that isn't strictly necessary, and give yourself 30 days to ship it. DM me your launch — I'll share it on the show." - Thank the listener voicemails - Ask for reviews/ratings: "If this episode helped you rethink your approach, a 5-star review helps other developers find the show" --- ### 43:30-45:00 — Outro + Next Episode Tease (1.5 min) **Next episode tease:** "Next week, I'm talking to a founder who built a $2M ARR SaaS using only Google Sheets as a backend for the first year. Yes, Google Sheets. That episode is going to break your brain. Make sure you're subscribed so you don't miss it." [HOST NOTE: The next-episode tease is deliberately extreme ("Google Sheets as a backend") to provoke curiosity. It aligns perfectly with this episode's thesis, creating a narrative arc across episodes.] **Sign-off:** Standard show sign-off, keep it under 15 seconds. --- ## EPISODE METADATA **Title options (A/B test):** - A: "Why Your Side Project Needs Worse Technology" - B: "I Shipped 1 Out of 11 Side Projects — Here's What the Winner Had in Common" **Description:** Include the Boring Technology Framework as a numbered list. Link to Dan McKinley's essay. Include the decision tree as a text graphic. **Tags:** side projects, shipping, boring technology, indie hacking, developer productivity **Suggested social clips:** 1. Cold open clip (0:00-0:45) 2. "11 projects, 1 shipped" story (2:00-3:30) 3. The decision tree segment (28:00-30:00)