001: How I Set Up My Build-in-Public System in One Session
TL;DR: Build-in-Public Pipeline in 60 Seconds
- Plan the whole pipeline before you build any of it. Map the system on a board first, then ship pieces in dependency order.
- Pick tools by your skills, not by industry default. The "right" tool is the one you will actually use on Tuesday at 3pm.
- Make the lead magnet honest. Show value first, gate second. Plain text beats designed PDFs for AI-native readers.
- Reuse infrastructure; never rebuild what works. One webhook plus a discriminator field beats N parallel endpoints.
- Test end-to-end with a real email before you declare anything done. Unit tests miss the seams between services.
A build-in-public publishing pipeline that turns each session into a YouTube video, an in-repo blog article, and a downloadable bundle of prompts plus working files. Built and shipped in one Claude Code session. The system itself is one thing; the principles behind it are the reusable part. This episode walks through both. The pipeline is opinionated. The principles are portable. Use them in your version.
Why this matters
After fifteen years in product management, the pattern that has not changed is that more than ninety percent of products fail. The reason is almost never the code. It is the thinking before the code, the communication after, and the loop between the two. This channel is the long version of that observation. I build a real product in public, fail in public when it happens, and document the decisions behind every commit. The episode you are reading is the meta layer: the system that publishes this channel. Five principles came out of building it. Use them in your version.
Principle 1: Plan the whole pipeline before you build any of it
I opened a Miro board and mapped the whole pipeline before I wrote a line of code. Three colors. Green for decided. Yellow for open. Pink for the headline of each cluster. The map went: YouTube video → blog article → downloadable prompts → newsletter subscriber → email sequence.
This is the single highest-leverage move I see teams skip. In my coaching experience, founders open the editor first, hit a wall around decision four, and spend three weeks "discovering" things they could have decided in twenty minutes with a marker. The board did not predict the future. It made the surface area visible so the order of operations was obvious.
The order matters. The journal page has to exist first because the YouTube description links to it. The email gate has to exist next because the description promises a download. The newsletter automation can wait because there is nothing to send to yet. Building piecemeal multiplies churn because every decision implicates the next two.
The three-color rule is portable. Green for decisions that are made. Yellow for open questions. Pink for the category headline so the wall has structure instead of being a sticky-note pile. The colors themselves do not matter. What matters is forcing every node into one of three states so you know where to spend your attention next.
The opposite of this is what I call "building by mood." You open the code editor, fix the thing that bothers you most, and call it progress. Three weeks later, the pipeline has eight half-built pieces, and none of them connect. The map costs an afternoon. The unmapped version costs a month.
Principle 2: Pick tools by your skills, not by industry default
The industry-default trap kills more solo creators than bad code does. There is a "right" video editor (DaVinci Resolve), a "right" automation tool (n8n or Make), a "right" CMS (Ghost, WordPress, Webflow). You pick them because everyone else did. Three weeks later you have not shipped because the tool fights your brain.
The fix is to pick tools that match your skills, not the consensus. Here are the five trade-offs I made on this build, with the reasoning.
| Decision | Picked | Rejected | Why |
|---|---|---|---|
| Video editor | Descript | DaVinci Resolve | I do not know how to cut video. Descript edits via text. The "right" editor is the one you will actually use. |
| Build layer | Claude Code + custom code | n8n / Make for building | When you can write code, integrations belong in code. Setup time on no-code tools eats the savings. |
| Routing layer | Make.com (one webhook) | Custom router | Make is correct for routing because that is what it does. Use it for routing only, not for logic. |
| Lead magnet format | Plain text | Designed PDF | The audience pastes prompts into Claude or ChatGPT. Plain text wins for AI-native readers. |
| Content layer | In-repo MDX | Headless CMS | Git is the source of truth. No external CMS to sync. Article changes ship with code reviews. |
The pattern across all five: choose the tool that costs you the least friction per use, not the one with the lowest setup cost or the loudest community.
In my coaching work I see teams batch the wrong things. Frontmatter decisions get rushed; integration credentials get deferred. Tool selection gets outsourced to "what the YouTubers use." Reverse it. Spend ten minutes per tool deciding what you will be doing on Tuesday at 3pm with that tool, and pick the one that does not punish you.
There is one more layer to this principle: dogfood the tools you teach with. This channel is about Claude Code, so the system that publishes the channel is built with Claude Code. If the tool can not run my own pipeline, why would I recommend it to anyone else? The same instinct applies to product teams in lean methodology. Use the methods you preach internally before you sell them externally.
Principle 3: Make the lead magnet honest
Show value first, gate second.
The conversion engine of this journal is the prompts section at the bottom of every episode. Prompt one is fully visible, unlocked, public. It is the strongest framing of the session, curated by me. Below it sits a single blurred preview card with placeholder text, and an email gate.
The reader sees the value before being asked to pay for it with their email. Most landing pages do the opposite: heavy promise, gate, then the reveal. That trains your audience to distrust your offers.
Plain text beats designed PDF for this audience. A coach I worked with last year sells a plain-text PDF for thirty bucks and makes money with it. The reason: the buyer pastes it into ChatGPT or Claude. They do not care about a logo. The fastest path to value is plain text. If complaints come in, you rebuild. Until then, you respect the minimum viable product principle and ship what works.
The flow respects both sides. Submit email, download starts immediately. MailerLite double opt-in confirms the address out of band. That is mandatory for German GDPR and I am not interested in dancing with the regulator. The subscriber gets the file instantly because that is the deal. The opt-in email is the seat belt.
Value for email is a fair trade. Do not apologize for asking. You are doing business and high-quality content costs you to produce. The reader who balks at giving an email for prompts they would otherwise pay thirty bucks for was not your customer anyway.
Principle 4: Reuse infrastructure; never rebuild what works
I refused to build a new endpoint for journal subscriptions. The site already has /api/newsletter for blog signups, and it does what I need: rate limit, CSRF, regex validation, disposable-mail blocking through the mailchecker library (55,000+ throwaway domains), and a clean POST to a Make webhook.
The only change I made was adding a discriminator to the payload. Every form now sends a formName field. Blog newsletter uses newsletter. Journal unlock uses productJournal. I added two extra fields for the journal route, episode_slug and lead_magnet, so I can track which episode converted which subscriber in MailerLite custom fields later.
In Make, I branched on formName == "productJournal" and pushed the subscriber to a new MailerLite group called "Product Journal" with double opt-in turned on. No new code on the server. No new automation framework. One identifier, one routing decision.
This is the playbook for adding new conversion surfaces to an existing site. Three rules carry the weight.
Add a discriminator field, not a new endpoint. A single formName string lets the router decide where the subscriber lands. Adding fields is cheap. Maintaining N endpoints with overlapping logic is expensive and a future-you problem.
Use routing tools for routing, not for building. Make and n8n are excellent at "if X then send to Y". They are terrible at "here is the business logic for what X means." Keep the business logic in code where you can read it.
Add tracking fields before you need them. episode_slug and lead_magnet cost zero to ship. Six months from now, when you want to know which episodes convert best, the data is already in MailerLite. Adding the tracking later means waiting six more months to learn anything.
In my coaching experience, the founders who get this principle right at the infrastructure layer build twice as fast at the product layer. The same instinct applies upstream. If you want help wiring the strategy before you wire the code, you can book a working session.
Principle 5: Test end-to-end with a real email before declaring done
I tested with test@test.com first. The disposable-mail filter rejected it. Good, that is the right behavior, and it tells me the validation pipeline works without me writing a single test.
Then I submitted my real email. The download started. The webhook landed in Make within a second. The Make scenario routed it to the right MailerLite group based on formName. MailerLite picked up the new subscriber and fired the double opt-in automation I had set up.
Four systems talked to each other on the first try.
That is the bar for "done" on a multi-system feature. Not unit tests passing. Not the form looking right. End-to-end, with a real email address, on production-like infrastructure. The number of "shipped" features that actually work the first time anyone tries them is shockingly low. Most break at the seam between services.
Live testing reveals what unit tests can not: misconfigured webhook URLs, wrong MailerLite group IDs, CSRF tokens that expired, GDPR confirmation emails landing in spam. None of these are catchable in isolation. All are catchable in two minutes with one real submission.
What is next
Episode 002 starts the actual game build. The pipeline you just read about is the foundation, not the product. The product is the game. The journal is the side-effect that keeps me honest.
If you are setting up your own build-in-public pipeline and want help wiring the strategy before you wire the code, that is the kind of work I do with founders one-on-one. Book a working session.
All prompts I used in this session
#1 Prompt
We need to establish a new blog on our project/website. We currently have /blog and I want to create a /journey. The /journey will be a journal of my build-in-public journey. You'll get the session logs as well as the transcript as well as the YouTube link, which must be provided within each particular article. No articles without video. The session logs contain a tracking of my Claude Code sessions and each prompt I've entered as well as a summary of the result. The prompts must be highlighted at the end of each article. We need to design that because: we show the first prompt, the rest is blurred and people can enter their email address which will create a subscriber in MailerLite and automatically start the download of the PDF file with all the prompts. Ultrathink, think deeply about it, ask questions if you have.