The argument in one line.
The hard part of building your own software has never been the code — it is deciding exactly what to build, and a PRD-first, milestone-by-milestone workflow makes that decision process repeatable for anyone regardless of technical background.
Read if. Skip if.
- You run a business and are overpaying for CRM software that does not fit your actual workflow.
- You want to build internal tools with AI but have been starting from a blank prompt and getting bloated or broken results.
- You have tried Claude Code or vibe-coding but your builds fall apart between milestones or drift from your original intent.
- You are a developer who wants to see a structured spec-driven workflow rather than ad-hoc prompting.
- You want a concrete example of how to break an app build into manageable, verifiable phases.
- You need a multi-tenant SaaS CRM built for many users — this explicitly builds an internal single-user tool.
- You are looking for deep Ruby on Rails or database architecture theory; the code is handled almost entirely by Claude.
- You already use a structured PRD and milestone approach — the workflow will be familiar.
The full version, fast.
Most people overpay for CRM software because off-the-shelf tools are built for 50,000 companies at once — bloated for everyone, perfect for no one. This video demonstrates a repeatable build method: write a rough feature idea, run a PRD Creator skill that shapes scope in/out decisions feature-by-feature and locks the data model, then break the PRD into five sequenced milestones each with its own generated Claude Code prompt. Each milestone runs plan mode first (translating requirements into an implementation plan), then execution mode, then produces a milestone log to hand context forward. The finished CRM — contacts, drag-and-drop Kanban pipeline, activity log, and follow-up to-dos — is done in one sitting. The central argument is that deciding what to build, and what to leave out, is the only skill the builder actually needs.
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.

01 · Why Build Your Own CRM
The case against renting bloated CRM software — you pay monthly for forty features you never touch while the three you need are buried five clicks deep. Intro to Brian Casel and the VibeCoder-to-Builder channel premise.

02 · Shaping the PRD
Using the PRD Creator skill inside Superconductor/Claude Code to convert a rough feature wish-list into a structured HTML PRD. The shaping process cycles through each feature deciding what is in vs. out, then locks the data model: contacts, deals, activity, tasks.

03 · Internal Tool vs. SaaS Decisions
Conceptual aside on how product decisions differ depending on who the tool is for. Custom fields as the key example: hard-code for internal, build a UI for SaaS. Scope decisions prevent AI slop.

04 · Buildable Milestones
PRD Creator outputs five sequenced milestone folders each containing a prompt.md. Milestones respect dependency order. The PRD HTML lives in the codebase as the living source of truth.

05 · Each Milestone Hands Off the Next
Milestone logs: Claude writes a milestone-log.md after each build phase capturing decisions made and a human-readable bullet list of what is new. Clears context, passes the baton forward.

06 · Plan Mode Then Execution
Milestone prompts drop into plan mode first — requirements translate into an implementation plan with clarifying questions on UI choices. Approval switches to execution mode. Claude builds autonomously.

07 · Reviewing and Refining Milestone 1
First live check of the contacts feature: search, create, edit, delete, mobile responsiveness all working. Small refinements via natural-language prompts: rename app, remove contact count.

08 · Milestones 2 and 3 — Deals and Kanban
Time-lapse through milestones 2 and 3. Check-in shows Kanban board with drag-and-drop, pipeline stage totals, list/board view toggle, and the multiple-contacts-per-deal fix applied via a single prompt.

09 · Testing and Verification
Claude runs automated regression tests after each change. All-green signal to proceed. Milestone log structure and test suite both generated by PRD Creator instructions in claude.md.

10 · The Finished Product
All five milestones complete. Final refinement makes the deals Kanban board the home dashboard instead of the placeholder screen. Full CRM in one sitting, most of it built while working on other projects.

11 · Get the Process
CTA for the free VibeCoder to Builder workshop at buildermethods.com/workshop and the free tools at buildermethods.com/tools.
Lines worth screenshotting.
- Off-the-shelf CRM software is built for 50,000 customers at once — bloated for everyone, perfect for no one.
- The hard part of building software was never the code; it was deciding what the tool should and should not do.
- For an internal tool, hard-coding pipeline stages specific to your business is a feature; for a SaaS it would be a bug.
- Explicitly listing out-of-scope items in your PRD prevents the AI from inventing features you did not ask for — this is what stops AI slop.
- PRD shaping should start high-level and drill down per-feature before a single line of code is written.
- Milestone logs are how you pass context between Claude sessions without re-explaining the whole project history.
- Plan mode and execution mode are separate phases — plan mode answers how to code this, not just what to build.
- Even experienced developers should let Claude handle small one- or two-line changes because it catches all downstream references a manual edit would miss.
- A design system template eliminates the need to design buttons, modals, and colors for every new internal tool.
- Regression testing after every milestone ensures new features do not break what was already verified.
- A full working CRM with contacts, Kanban pipeline, activity log, and follow-up reminders can be built in under one hour of real build time.
- Custom fields in a CRM are a product decision, not a technical one — the right answer depends entirely on whether the tool is for you or for a market.
- Writing what you are NOT building is just as important as the feature list.
Scope first, code second — always.
Every failed AI build shares the same root cause: the scope was never locked before the coding started.
- The core problem with renting software is that it is optimized for 50,000 customers simultaneously, which means it fits no single customer's workflow precisely.
- Building an internal tool means you only pay once — in time — rather than paying monthly for features you never use.
- Start the shaping process with a high-level feature list confirmation, then drill down to per-feature scope decisions — this layered approach catches scope creep before the build starts.
- The data model decision (what are the main entities: contacts, deals, activity, tasks) should be locked early; everything else in the PRD depends on it.
- An HTML PRD is more scannable and shareable than a markdown document — worth the small extra step if you will revisit it repeatedly.
- Custom fields are a SaaS feature, not an internal tool feature — for a solo or team internal tool, hard-code the field names and stage labels specific to your business.
- Every product decision changes depending on who the user is: yourself vs. a market of strangers requires completely different implementation choices for the same feature.
- Milestones should be ordered by dependency — you cannot build Kanban until deals exist, so deals is always milestone 2 and Kanban is milestone 3.
- Each milestone folder containing a ready-to-use prompt.md eliminates re-explaining the project scope every session — the prompt already has the context baked in.
- The milestone log is the handoff artifact — it is not for the human to read in detail, it is for the next Claude session to read before starting work.
- The human-readable bullet list at the top of the milestone log tells you exactly what to test in the browser after each session, acting as a mini acceptance criteria list.
- Plan mode is a second layer of planning on top of the PRD — the PRD says what to build, plan mode says how to code it; both layers together dramatically reduce mid-build surprises.
- When Claude asks a clarifying question in plan mode about a UI choice, ask for the trade-offs if you are unsure — that single question surfaces the decision criteria without requiring technical knowledge.
- After each milestone, test exactly what the milestone log says was built — use the bullet list as your acceptance checklist rather than clicking around randomly.
- Small refinement prompts at end of a milestone context are cheap and normal; the planning phase prevents big redesigns but not paper cuts.
- Automated regression tests are not optional polish — they are the only reliable signal that new milestone code did not break previously verified functionality.
- Letting Claude write and run its own tests means the test suite grows automatically with the codebase without requiring you to write test cases manually.
- A complete functional CRM — contacts, Kanban pipeline, activity log, follow-up to-dos — can be built in one sitting even while working on other projects in parallel.
- Final quality-of-life changes like setting the deals board as the home dashboard are one-sentence prompts; the planning phase means even late-stage changes do not require rework.
Terms worth knowing.
- PRD (Product Requirements Document)
- A structured document that captures what an app should and should not do, including scope decisions, data model, and per-feature specifications. Used here as the single source of truth that guides every Claude Code session.
- PRD Creator skill
- A custom Claude Code skill that guides the builder through a shaping conversation — high-level features, in/out scope, data model, per-feature details — then outputs an HTML PRD and numbered milestone folders each with a ready-to-use prompt.
- Milestone log
- A markdown file Claude writes at the end of each build milestone summarizing what was built, technical decisions made, and what is new in the app. Passed into the next milestone prompt so context survives across cleared Claude Code sessions.
- Plan mode
- A Claude Code operating mode where the AI reads requirements and produces a technical implementation plan with clarifying questions before writing any code. Distinct from execution mode.
- Superconductor
- A third-party desktop application that lets you run multiple Claude Code projects simultaneously, switching between them without losing context on any individual project.
- Build New
- A Ruby on Rails starter template created by the presenter that includes a design system skill, authentication scaffold, and consistent UI shell — used to skip boilerplate setup on every new internal tool.
- Regression testing
- Re-running previously passing tests after adding new features to confirm that the new code did not break anything that already worked. Used here after every milestone and every refinement prompt.
- Kanban pipeline
- A board-style view where deals are represented as cards in columns (pipeline stages) that can be dragged and dropped to change their status. Common in CRM and project management tools.
Things they pointed at.
Lines you could clip.
“The hard part was never the code. It was deciding what this thing should and shouldn't do.”
“Deciding what you're NOT building is just as important as making the list of what you are building.”
“It's almost like an employee coming to my desk and saying: here boss, here's what I've built. Check it over.”
“Even as a long-time developer who used to code all of my apps by hand, now I leave it to Claude Code.”
Word for word.
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
The bait, then the rug-pull.
Nearly every business is overpaying for a CRM that does forty things it never touches and buries the three it actually uses five clicks deep. In this 36-minute build, a developer-turned-methods-teacher tears down that argument live — starting from a blank Claude Code project and ending with a working Kanban pipeline, contact manager, activity log, and follow-up system, all shaped by a structured PRD and built milestone by milestone with Claude Opus.
Named ideas worth stealing.
PRD-First Milestone Build Method
- Write rough feature idea (no technical detail required)
- Run PRD Creator skill — shapes in/out scope, data model, per-feature decisions
- PRD outputs HTML document + numbered milestone folders each with prompt.md
- For each milestone: plan mode first, then execution mode, then milestone log
- Quick refinements at end of each milestone before clearing context
- Repeat — each milestone log hands context to the next
A six-step repeatable process for building an internal tool from blank idea to finished app using structured planning documents and sequenced Claude Code sessions.
Internal Tool vs. SaaS Decision Filter
- Internal tool: hard-code specifics, skip custom-field UI, move fast
- SaaS product: build configurability, custom fields UI, flexibility for many customers
Every product feature decision should be filtered through who the tool is for. The same feature (e.g., pipeline stages) has a completely different correct implementation depending on whether you are building for yourself or for a market.
How they asked for the click.
“If you want me to walk you through my exact method for building apps with AI, start to finish, that's in my free workshop called VibeCoder to Builder at buildermethods.com/workshop.”
Clean verbal CTA with URL repeated twice — once mid-video during tools mention and once at close. No on-screen overlay or link card shown in the recording.





































































