Modern Creator
Brian Casel · YouTube

How to build your own CRM (start to finish)

A 35-minute live build of a lean sales CRM — contacts, Kanban pipeline, activity log, and follow-up to-dos — using a PRD-first, milestone-by-milestone workflow with Claude Code.

Posted
4 days ago
Duration
Format
Tutorial
educational
Views
4.9K
134 likes
Big Idea

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.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…
  • 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.
SKIP IF…
  • 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.
TL;DR

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.

Free for members

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 →
Chapters

Where the time goes.

00:0001:39

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.

01:3906:30

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.

06:3011:52

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.

11:5214:59

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.

14:5916:53

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.

16:5320:10

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.

20:1022:15

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.

22:1527:15

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.

27:1531:57

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.

31:5735:29

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.

35:2935:59

11 · Get the Process

CTA for the free VibeCoder to Builder workshop at buildermethods.com/workshop and the free tools at buildermethods.com/tools.

Atomic Insights

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

Scope first, code second — always.

BUILD METHOD

Every failed AI build shares the same root cause: the scope was never locked before the coding started.

01Why Build Your Own CRM
  • 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.
02Shaping the PRD
  • 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.
03Internal Tool vs. SaaS Decisions
  • 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.
04Buildable Milestones
  • 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.
05Each Milestone Hands Off the Next
  • 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.
06Plan Mode Then Execution
  • 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.
07Reviewing and Refining
  • 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.
08Testing and Verification
  • 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.
09The Finished Product
  • 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.
Glossary

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

Things they pointed at.

Quotables

Lines you could clip.

35:11
The hard part was never the code. It was deciding what this thing should and shouldn't do.
Clean standalone thesis, no setup needed, lands the core argument of the entire channelTikTok hook↗ Tweet quote
07:00
Deciding what you're NOT building is just as important as making the list of what you are building.
Counterintuitive, contrarian to most build-fast messaging, tight sentenceIG reel cold open↗ Tweet quote
15:00
It's almost like an employee coming to my desk and saying: here boss, here's what I've built. Check it over.
Vivid metaphor for the milestone log handoff — immediately relatable to anyone who manages peoplenewsletter pull-quote↗ Tweet quote
33:30
Even as a long-time developer who used to code all of my apps by hand, now I leave it to Claude Code.
Credibility + permission — removes the objection that real developers still code manuallyTikTok hook↗ Tweet quote
The Script

Word for word.

Read-along

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.

metaphor
00:00The most useful skill in business right now isn't coding. It's being able to build the exact tool that your business needs instead of renting one that kinda sort of fits. And the part that everyone assumes is the hard part, the actual building, that's the part that you can learn.
00:13And I've been a developer for years, way before AI came along. And so what I try to do here is I try to point you straight to the parts of the workflow that actually matter. So today, we're gonna keep it broad.
00:23I'm gonna build a CRM. That's the tool that nearly every business is overpaying for. So you can see my whole approach to building a new app end to end.
00:31And as you'll see in the other videos on my channel, this same process applies no matter what tool you're building for your business. The moves never change.
00:39So look, here's the thing about the big CRM software tools. They're all built to sell to 50,000 companies at once, which means that they're bloated for everyone and they're perfect for just about no one. So you're paying every month for a pile of features that you probably never touch.
00:54And meanwhile, the two or three things that you do actually use are buried like five clicks deep. Does that sound familiar? So let's build our own.
01:02A lean CRM that does exactly what you need and nothing else. Now, I'm gonna show you exactly how I would go about this, but what I really want you to take away here is that you can design and customize the perfect CRM for the way that you actually work because that's what building your own tools is all about. Now, if you're new here, I'm Brian Castle.
01:21And on this channel, I build real apps with AI and I show you how to build the tools that your own work needs, whatever field you're in. And if you want my full method, I put together a new free workshop on going from VibeCoder to Builder and that's @buildermethods.comslashworkshop.
01:37Okay. Let's build. Alright.
01:39So I started up a fresh application. We'll be working in Claude code today for basically everything. I am using an application that's called Superconductor that I really like, and it allows me to work on multiple different projects at the same time.
01:53Once you get really good at building tools, you start to multitask quite a bit. But today, we'll just be focusing on this one here at the top, which I will call simple CRM. And, um, and yeah.
02:04So I am starting with, like, my starter application template. It helps me get up and running pretty quickly. And by the way, I'll be using a couple of free tools that I use in my tech stack and my workflow today.
02:17And you can get access to all these by going to buildermethods.com/tools. So build new is my application template.
02:25It's like a starter template that I use to get me up and running quickly. It's a Ruby on Rails based application. I'm gonna be using that.
02:33That also comes with my design system built into it. It's actually a skill that's built into it, and you'll see that come into play as we start to, uh, put together this application.
02:43But most of all, we'll be in my PRD creator skill, which will kind of walk through the process of planning and shaping and creating a PRD or a product requirements document, and then break that out into milestones that we will build out this for this tool that we're building today.
03:00So these are the free tools that are available here and I'll be using them to kind of power this process going forward. Now, uh, but yeah, let's get right into it. Now I'm gonna start off by invoking my PRD creator skill.
03:13So I'm just gonna get that going here. So I already have that installed and Now the first thing that the process is going to ask for is what's the basic idea? What are we building today?
03:22Right? Doesn't have to be super detailed. Doesn't have to be super technical here.
03:28I prepared a little prompt here. Here, I'm just saying, I wanna build a simple CRM tool. These are the main features that I think that it should have.
03:36We need the ability to manage a list of contacts and store some information on them. A way to track details that are, you know, that are of different status. A way to track deals that have different status, and can give a deal value like a dollar amount.
03:52And I like to use Kanban, so let's have a Kanban view where I can, like, drag and drop deals across the pipeline. And it would also be good to have like an activity log with time stamps and like a kind of details or of like the events that happened throughout the history and the life cycle of a deal.
04:12I think really important for any sort of like sales CRM tool is to have a to do list to remind us of the next action that needs to be taken on every deal whether So that's our starting point for this, and I'm just going to give that to Claude. Now now, PRDs or project requirements documents, typically, they've been done, they've been created using markdown.
04:33But these days, I like to create them in HTML, which is a little bit more visual and, uh, and easier to see. So the skill does give me that option. I'm going to go with the HTML option.
04:43And now we're gonna get into the actual shaping process where we're gonna start to make some high level and some detailed decisions upfront. And I think that this is really the most important thing that we do as builders now is shaping up these detailed plans or specs or PRDs.
05:02These are all different words for the same thing, really. Alright. So we're gonna start with a high level overview, and Claude gave us that.
05:08That's looking pretty good. So the process of shaping up a detailed spec or PRD is to start high level and then start to drill down to get more and more granular as go along.
05:20So we're gonna start by just listing out the main features and this mostly mirrors what I already gave it in my original prompt, but it adds a little bit more detail and organization and it's just sort of like a way to sort of confirm like, is this what we're building? Yeah. I think that looks pretty good.
05:34So we're gonna go ahead and confirm. And now we take the flip side of that. So we just a v one, we're keeping it very simple and lean, and so we're actually making the list of things that we are not building.
05:46And this is just as important as making the list of what we are building. Because if you don't do the type of this type of step or this type of being, you know, this level of being explicit, then, you know, your LLM could end up dreaming up the extra features and bells and whistles that you didn't necessarily ask for.
06:06And that's how we end up with AI slop and, uh, features that just don't work. Now, one thing I really wanna point out here is this idea of custom fields.
06:17Right? Or custom pipeline configuration. Now, there are a lot of these like product decisions or tool decisions that really come into play when you're making a product that's only for you to use internally or maybe for you and your team to use versus making a product that you're going to sell as a SaaS to many other customers or like a whole market of potential users.
06:45Very different product decisions come into play there. Right? And I think custom fields is a really good example of something that I would think very differently about depending on which type of situation I'm in.
06:57An internal tool versus an external, like, sellable SaaS tool. Since this is gonna be an internal tool that only I plan to use for myself, I don't actually need a whole interface or the complexity of needing to have needing to create and manage custom fields, like custom fields on contacts or custom pipeline stages.
07:21Instead, I'm perfectly okay with hard coding those into the actual code base, even if they're highly specific. Even, let's say, like, I'm a music producer and I need to have one stage in my pipeline that says something like, it has reached the mix down or the mastering stage. That's very specific to my business.
07:40Normally, if this were a SaaS that I was selling at the external market, I wouldn't hard code something like that into the code itself, but I would wanna make it flexible for all of the customers of my SaaS to be able to customize their own sets of custom fields. But in this case, it's an internal tool that only I'm using, so I can hard code whatever details I want into it.
08:01And I have the benefit of getting to avoid building complex user interfaces like these. So we figured out the high level scope of which features are in versus out.
08:13Now, we're up to a pretty important step in the shaping process and that is, uh, the initial data model. This early stage, all we're deciding are like what are the main entities or the main things that we are building into this application.
08:27So this is a simple CRM. Of course, we're gonna need, uh, a concept of contacts, like the person with these specific fields.
08:36Right now, I'm really just focused on the on the first line of these items, which is like we're gonna have contacts, we're gonna have deals that we're gonna be able to track, we're gonna track activity, We're gonna track tasks.
08:48And it gave me a few other notes here. So if I have anything missing, I can go with this option or I can type in and add some details or questions and discuss it.
08:58But I think that this looks right. So let's go ahead and lock it in. Now, you'll hear me or Claude use the term lock it in quite often throughout this process.
09:09All that means is we're we've made a decision and we're now going to plan on doing it that way. Nothing is actually set in stone. This all lives in code and we manage our own our own tool here so we can just use Cloud Code to make adjustments later.
09:23But the more key decisions that we can make upfront, the better and more predictable this whole process is gonna become. Alright.
09:31So now we're gonna start to get a little bit more granular. Remember, we're starting high level and we are now getting down into each individual feature. We're gonna cycle through each of the six big features and do the same thing that we did before deciding what's in scope versus out of scope, except we're gonna do that at a more granular level within each individual feature.
09:54So starting with the contact management, here is exactly how that feature is going to work. A list of contacts with their name, company, email shown on the list view, and then the ability to view the contact's details, edit and delete a contact.
10:09So so from the outset when you start this process, you don't have to dictate every one of these technical or user interface details. Luckily, can have Claude sort of suggest the obvious interface and you can just course correct or confirm and say, yeah, that looks good.
10:26Alright. So now I'm just gonna kind of follow the same process as we go through the rest of these features. Alright.
10:31So here we're up to the Kanban pipeline and this is a really important feature to me because I'm such a Kanban thinker and a Kanban user. Alright.
10:39Now that we've gone through all the features, we've locked in what's gonna be in scope versus out of scope for all of them. Now we get up to the next part of the planning phase and that is like how we are gonna actually build this thing.
10:52Specifically, are the different milestones and the order in which we're gonna be building that. So, uh, PRD creator skill helps with this part as well.
11:01It recommends that we break this thing up into five buildable milestones. These are balanced checkpoints and, uh, their natural dependency order came into place.
11:12So that means that, like, we can't build the Kanban pipeline until we already have built contacts and deals. Right? We can't build activity until we've built deals.
11:23So, you know, it takes those types of considerations when it sets the order of the milestones. But I think we'll just go with the five now. Okay.
11:31So now it has everything that it needs. So it's gonna go ahead and build out the detailed PRD, the project or the product requirements document.
11:41That's gonna be like our source of truth or like our main road map, if you will. So it's gonna work on that, and then it's gonna also break it out into buildable milestones so that we can start to build this thing. Okay.
11:52So our PRD for building our simple CRM app is all set. So what the PRD creator skill did for me here is it actually created a folder in my code base called build plan.
12:07And if I open that up, we've got a folder called milestones and we have p r d dot h t m l. So let's first look at our actual p r d. I'm gonna open this up.
12:19And that is an HTML file, so I can just open it up in a browser. And here we go. Here is our product requirements document designed in a nice, easy to read, easy to scan PRD.
12:31So this has all of the details that we discussed, you know, starting with like what the app does, and then what's in scope and out of scope.
12:40We've got that data model that we discussed. These are and then we get into the milestones. You know, this is gonna be sort of the road map for how we build this out, starting with the contacts, deals, and then the Kanban pipeline, the activity log, the follow ups.
12:55And so, yeah, this this is a nice handy document to sort of guide our way throughout the process. Most of the time I stick to this and our prompts, which I'll show you here in just a second, are gonna help us stick to this.
13:08Sometimes things change and and, you know, this is just an HTML document that literally lives right here, right in our code base. So if anything changes, I can always say, hey, update our PRD because we're midway through and we've changed some plans and let's make sure that we can stay on track.
13:25That happens from time to time, not a big deal. But I think this is a really good starting point for getting us going. Now, what it also did was it created those milestones.
13:36So inside of the milestones folder, we have these numbered folders, one for every milestone, and this follows those five milestones that we had agreed to earlier in the right order.
13:49Right? So what's nice here and I designed this into my PRD creator skill because I just don't wanna repeat myself very often.
13:58And so what happens is inside each one of these milestones, have this little prompt dot m d. So I can look at that and this is actually the prompt that I'm going to give to Claude code to build milestone one.
14:12So let's go ahead and do that. Now, I can do that a number of ways. First of all, I'm in Claude code.
14:18I'm gonna clear this so that we get a clear context window. I can very easily just take this markdown file and drag and drop it right into there. It's basically saying we are gonna build out milestone one.
14:31I want you to enter plan mode and I'm gonna do that in just a second. But here's the context. To read what we are gonna build in milestone one, go ahead and read that PRD HTML and focus only on building milestone one.
14:46Now, a key thing and it doesn't happen automatically with Clog code, this is just something that I like to do is I like to have Claude write up its own milestone log document when it does that work. So that when we move from milestone one into milestone two, it'll have a record of all the decisions and details that were done in milestone one.
15:08In case anything came up along the way, so that when we clear the context again and we build milestone two, it has all that stuff. Anyway, let's get going on milestone one.
15:17Gonna come back here and I'm gonna make sure that I switch into plan mode. And so we've got that here. I can see plan mode is on and I'm going to run this prompt.
15:29Now, you might be wondering why are we going into plan mode if we've already planned planned out the PRD. I like to take a layered approach.
15:40Again, I can't stress this enough like planning and then oh, and then planning and planning is actually very helpful. But the difference between what we did earlier with shaping up and making the PRD and what we're doing doing now is we've already defined what it is exactly that we're going to build in milestone one in terms of the requirements, like we're building out the contacts feature.
16:02But what plan mode does in Claude code is it takes those requirements. It's gonna read them off of the PRD and it's going to make its actual coding implementation plan.
16:14It's like, okay, we know what you wanna build. Now, how are we gonna actually code this up technically? And this a this is a level of planning that's probably more technical than most people even need to read at this point.
16:27If you want to be really detail oriented, read every line of the plan that it comes up with, by all means, go ahead and do that, especially if you might spot things that are a little bit off. But we've done so much upfront planning in that in that PRD already that I feel pretty confident that whatever it's gonna put together in this technical plan is gonna be pretty well aligned with what I'm expecting.
16:53Alright. Now, Claude just needs to confirm a few technical or UI, UX details as it locks in its implementation plan.
17:02Again, I know we're sort of like cycling through stuff, but we're getting even more granular at this level. And we're just ensuring that Claude and, you know, the coding agent here is going to really have what it needs to make well informed, well aligned decisions with what we actually want out of this tool.
17:20Right? Alright. So and I love, like, the little mini illustrations that they do here.
17:24So, yeah, let's go with that. How should search and sort by name work? And the options here are server side and client side.
17:32Now, you know, I have a developer background, so I know what those mean and like the trade offs that are involved there. But, you know, if you don't have a technical background, you know, you might not be totally clear on exactly what's the difference here.
17:45What is it actually asking me? So I just wanna demonstrate to you like how I would go about clarifying that. Right?
17:52So you can go down to chat about this and say, you know, I could say something like, what did you mean with your question about search?
18:02What are the trade offs? I think that's sort of like a magic question that you can ask as somebody who might be less technical, not technical. What are the trade offs?
18:13That's that's a really good question because that's gonna give you like an informative answer about that will actually help you make the right decision for what your priorities are.
18:25So sort of give me a rundown of like the difference between what server side means and client side means. Alright.
18:31So it asked me a question about the navigation. We're gonna go with that option and yeah, we'll submit those answers. Okay.
18:37So it's gonna go ahead and write up the plan. Okay. So the technical implementation plan is now complete.
18:43This is like the end of plan mode. Now, I'll be honest, like, in my experience, even as someone who's more technical, I tend to just sort of like skim over this. And the reason why I feel confident enough in just skimming and not really worrying too much about every single detail in here is that we did spend so much time upfront during the PRD planning stage that I'm confident that, you know, today's latest models, I'm using Claude Opus today, can translate those requirements into a very accurate and well well crafted technical plan.
19:16So, you know, I'm pretty confident in that and I'm I'm gonna go ahead and proceed. We're gonna say yes and bypass permissions. Alright.
19:23So now we've switched over from plan mode now into, you know, execution mode and Claude is gonna get to work.
19:32Now you'll see how it will like create its own to do list based on the plan that it created and it's and it's just gonna go ahead and cook on that. Now at this point, it's it's gonna work. It's probably not gonna take very long, but if this were like a bigger milestone, like, could just go jump over to one of my other projects and continue planning or building one of those, or I can go take a walk.
19:54I might I might go to bed and pick up in the morning. That's kind of the nice rhythm that I like to feel at this point of, like, letting Claude cook on something, and then I can move on to something else and just really be productive while I'm actually building pretty valuable tools in my business.
20:10Okay. So milestone one is done here.
20:13So I can see that it already finished up. It says that Claude crunched on this for almost twelve minutes. Not bad.
20:20Alright. So we've got milestone one all finished up.
20:23So now we're gonna check it out. Now it did write up the milestone log and that's here.
20:30Now you'll see that there's quite a bit of detail in here and it's all pretty pretty technical, you know. It goes into like what was built on the front end, the back end, some tests that were written.
20:40So we've got some pretty good test coverage, some technical decisions during implementation, you know, things that were not necessarily specified in the PRD. Now again, this is something that like I don't really need to get too deep in the weeds on reviewing or even necessarily understanding every bit of this.
20:57And so it's okay if you don't. These are really just technical notes that the coding agent from milestone one is writing up and passing over to the coding agent who will be building out milestone two.
21:11That's why I think this is one of the most valuable moves that you can make when you're building multiple milestones is having these little having Claude write up these log files to pass the baton over. Right?
21:23But there's one section right at the very top of the milestone log. And I find that this is a very helpful human readable simple bullet list of what's new in the app.
21:36Like, what was just built in this milestone so that when I check it out in the server, which I'm about to do now, I know what to look for. Like, I should this is almost like an employee coming to my desk and saying like, here boss, here's what I've built.
21:50Check it over. And so now I see what I'm able to start testing out in, uh, browser. Right?
21:56So let's go ahead and run the server and check this thing out. Do it. Okay.
22:02So here we go. So I'm actually logged in now to my application. Now, the design is pretty bare bones.
22:10It is using this like shell design that is actually built into my design system. The design system came built in with my build new application template.
22:21It's all of those are free. You can get those at buildermethods.com/tools. So this is a pretty consistent layout that I will always have, like, this nice navigation.
22:30The design system has all sorts of other stuff built into it, colors, buttons, menus, modals, all sorts of stuff that we will use throughout the UI. You notice that the name build new, which came from my template has not actually been updated yet to be the name of this application.
22:48So that's something that I'm gonna ask it to fix. But let's go ahead and actually test out what was built here in milestone one and that is the contacts feature. Right?
22:58Okay. So right off the bat, I do see that we have a contacts page.
23:02There are zero contacts. That looks a little bit Alright. Well, let's go ahead and try creating a new contact.
23:08It launched a modal. One of my Alright. So here's the notes field.
23:12Does this support markdown? No, it doesn't.
23:16Okay. That's probably okay for now. Alright.
23:18Very nice. So we've got our first contact and if I click it, now we have this contact detail page.
23:24Alright. Let's go ahead and add another one. Very nice.
23:26Okay. So I have two so I have two contacts here.
23:30Now, let's see if I can search by name. Yeah.
23:34Cool. So that actually filters down the list. So that's really nice.
23:37And I can hit escape and that works as well. I noticed that this persists.
23:43Now, let's check out the mobile version to see if this is all mobile optimized and it is. So that's looking good. And let's see about this.
23:53Now again, like this mobile optimization, the responsiveness is actually built into these templates and components.
24:01Actually, pretty much all of these UI components that we're seeing here are part of the design system that comes with my design system skill.
24:12I'll actually show you that here. So if I go into my admin and then if I go to into design system, all of this just gets automatically built into your app when you use my design system skill.
24:25And I did another whole video on the channel walking through this design system feature and you can it's all free. You can get that at buildermethods.com/tools.
24:33So, you know, I just kinda wanted to show you that like all of my apps use that and this is where, you know, we have all the colors defined and all sorts of other stuff. And so this is when I get into a little bit of like rapid fire tiny prompts to just like refine small things before I move ahead into the next milestone.
24:51So we're here still at the end of milestone one. I am not going to clear the context.
24:58I could, it's not a big deal, but I like to do these refinements at the end of the context window of what was just built, especially if I need to fix something that was specifically built during this milestone. But, uh, for now, I'm just gonna do a couple of small things. Uh, can you update the name of the app shown in the top left corner from build new to simple CRM.
25:19That should be a quick fix. And there we go. Now it's a simple CRM.
25:23Nice. Again, I didn't really like having this count. It doesn't really help and it so I'm also gonna say, remove the contacts count at the top of the contacts page.
25:34Just little refinements, you know.
25:36I find that especially when we've gone through the extensive planning phase and when I'm using a design system, it's basically good to go and I don't have a lot of like detailed fixes or redesigns or things like that.
25:52It's just kind of cleaning things up a little bit here and there. As we get, as we move along and add more and more functionality, more complex functionality, it's not uncommon for me to spend ten minutes, thirty minutes, sometimes an hour or so going through and having it rework and fix things.
26:08But it's never like wholesale just completely, this is all wrong, let's build it again, like, the planning phase avoided anything like that. Alright.
26:16That's done. So I'm gonna go ahead and commit and push this to my GitHub repository.
26:22Okay. So now we finished milestone one and now I'm gonna move on into milestone two. So here we go.
26:27I'm gonna go into the deals list view and I can look at the prompt. It's exactly the same as it was for milestone one. The only difference is that this time actually, uh, it's actually going to read the previous milestones milestone log because that actually exists now for milestone one.
26:45But everything else is the same. It's basically just instructing it to work off of everything that's in milestone two from the PRD. So we're gonna go ahead and do that.
26:54I'm gonna bring that prompt in here. And really, I'm just gonna follow the same exact process as I did before.
27:03And we're going to start plan mode and I'm just gonna kinda run it back. And this is gonna be like a repeatable cycle that I do for every milestone going forward. So I'm gonna push forward with a few more milestones, then I'll check back in a few minutes.
27:15Alright. So I'm making good progress. I'm now up to milestone three.
27:18We've just completed milestone three, which is the Kanban view. So we've now built deals and Kanban. So let's take a look and see how we're doing.
27:27So we've got the contacts which we've built before, and now we have the deals page where we have a board view and a list view. But actually, you can see that we don't have any actual deals in the system yet.
27:38So let's go ahead and add a deal. Alright. So we've got these pages sort of hard coded into it.
27:45And remember earlier when I, uh, decided that these are the actual stages that I want in my application, I can see that has been reflected here. So nice and aligned to what exactly I wanted. Cool.
27:56Which contact is this going to be associated with? Let's associate it with this contact. And you know what?
28:01That's something that I probably wanna change because it currently only allows me to associate a single contact with a deal, but it's quite possible that I would have multiple contacts associated with a deal.
28:14So I'm gonna need to update or have Claude update that UI so that I can select multiple. And let's add some notes about this deal.
28:23Alright. So now we have one deal and since we have at least one deal in here, now I can see that we have an actual Kanban view. Okay.
28:31Very cool. And let's try the drag and drop. Very nice.
28:35And I also like how it updated the total on here. Now, I don't love how width is sort of constrained.
28:43Let's go ahead and add another deal. Deal b. This one will be 8,000.
28:48Okay. So it correctly added them up. And I can drag and drop to change the order within a column, which is something that we specified during the early shaping phase.
29:01Right? Let's take a look at list view. Okay.
29:04Very nice. So I can actually sort by lead and by value. That's looking very nice.
29:10Even this too can be wider when I when I have a very wide screen like I do here. So the two refinements that I wanna make now are the ability to associate multiple contacts with a deal, and I want to make the board and list view wider.
29:27Yeah. On the board and list view, make the maximum width wider.
29:33When associating contacts with a deal, I should be able to select multiple contacts and associate multiple contacts with a deal.
29:43So just little details and since, you know, I'm the owner of this app and you would be the owner of your app, you wanna look for these little paper cuts. The things that you know are gonna be kind of annoying or just not gonna work for your process. For example, I know that, like, I would need to associate multiple contacts with a deal, so we can just fix that.
30:04We can just build that instead of wish that like some SaaS tool off the shelf had this or that feature or worked a certain way. Now we can actually craft our own tools.
30:14Incredible. By the way, another thing that's happening sort of under the hood here, I talked about how it, you know, it writes tests and it verifies in the browser. It also continuously tests.
30:26So as and since we've already built things before and now up to we're like near the end of the milestones list and we're making some changes. Notice how it retests to make sure that the full suite still passes.
30:41All green means that they they've all passed. That that's what we call regression testing.
30:46Right? We want to make sure that even though we've built some stuff before and we tested it before and it was passing before, now when we make now when we add new features and if we have to make new fixes or new changes to our functionality, we have to retest to make sure that whatever we just added now did not break something that we had previously tested and built earlier.
31:07So that's that kind of stuff is all built in to the instructions that Claude is gonna use.
31:13That Those come from claude.md. So again, it just adds more and more confidence that what I'm building is not breaking along the way.
31:20I'm gonna run the browser and So this is much wider now, so that's good. I can move these around. Very nice.
31:27And when I edit it, I can actually assign multiple contacts. So that is cool.
31:33And they're yeah. Looking we're looking pretty good here. Alright.
31:35I think I'm just going to finish up this final milestone and then we should be in pretty good shape. So once again, I'm just going to clear this context and I'm just gonna oh, actually, we have two more milestones. My mistake.
31:48So we're gonna do activity logs and then the follow-up reminders to do. So I'm gonna push through those and, uh, and I'll check back in when those are all built. Okay.
31:57So our simple CRM is mostly complete here. So all of the milestones have been completed.
32:03So let's, uh, check it out in the browser and see how we're doing. Alright. So we still have this like temporary home screen.
32:10So that's something that I'm gonna wanna fix in just a minute, but okay. So we have our contacts which we looked at before and we have our deals which is much wider now.
32:20And I like how I can now see a to do list. So if I look at a deal, I can schedule a follow-up.
32:29I can pick a date and time for that, and I'll schedule that. So that looks good.
32:35And then I can go into the to do list and I see it there. Of course, that links me back to that deal in the CRM and can like check this off and we're all set. Very nice.
32:47So pretty simple, you know. Uh, the idea is that this is supposed to be a simple CRM, but now I whipped this up in like just, you know, all of this was just today in less than an hour and I was actually doing other projects while I was working on this.
33:01So that's pretty cool. Let's go ahead and clean this up. I think that for a simple CRM, I probably wanna have this deals board be the home dashboard.
33:12So let's go ahead and have Claude fix that up for us. Let's make the deals board view be the home dashboard view.
33:21So get rid of the temporary dashboard view and when the user logs in, the first thing that they should see is the deals board.
33:31So the nice thing is like, you can just speak in normal terms. We don't need to give like highly technical direction as long as you're detailed in what you mean and what you're going for and what the outcome that you're going for.
33:44Typically, Claude would understand what you're going for and if it's unclear, Claude should ask you some clarifying questions to help you make the right decision as to what you wanna do. And by the way, that change that I just asked for was super simple and it's almost like so simple that it's like, why don't I just go into the code and change it myself?
34:04It's probably just one or two lines. These days, I don't touch the code at all. And actually, that's a good thing because, you know, you can see here in the in the work that it's doing, it is more than just a line or two.
34:17You know, it has to find all the different references that point to the dashboard and make sure that those are updated to make sure that like anything that is affected here, we are we're updating correctly.
34:29So you if you are technical and you can code, I actually find it's more effective to just let Claude make even the simplest changes. It can be that much more thorough and there are all these little things, gotchas that I can just take extra time to work out or you'll probably forget about them anyway.
34:48So that's why I'm like, even as a long time developer who used to code all of my apps by hand, now I do just leave it to Claude code because I can give it the instruction that I need.
35:00And even if you don't code, it's easy enough to just speak in human terms. That's what's so interesting and kind of fun about building tools these days.
35:08Alright. So that fix should be all set. I'm just gonna run the server and yeah.
35:13We're now deals is the main page where when you're logged in. So yeah. That looks pretty good.
35:18So, you know, this is a simpler one, but that's the idea. And, yeah, this is a fun little build. So it's something that I can probably like build on top of and maybe add to depending on what my business actually needs.
35:29So that's a working CRM built from scratch in one sitting. And notice that the hard part was never the code. It was deciding what this thing should and shouldn't do.
35:38But really, that's the part where you're already the expert since that's your work. 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.
35:50And it's over at buildermethods.com/workshop. And if you like this video, hit subscribe so that you don't miss my next build here on the channel. See you next time.
The Hook

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.

Frameworks

Named ideas worth stealing.

01:39model

PRD-First Milestone Build Method

  1. Write rough feature idea (no technical detail required)
  2. Run PRD Creator skill — shapes in/out scope, data model, per-feature decisions
  3. PRD outputs HTML document + numbered milestone folders each with prompt.md
  4. For each milestone: plan mode first, then execution mode, then milestone log
  5. Quick refinements at end of each milestone before clearing context
  6. 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.

Steal forany internal tool build — especially when scope creep or mid-build drift has been a past problem
06:30concept

Internal Tool vs. SaaS Decision Filter

  1. Internal tool: hard-code specifics, skip custom-field UI, move fast
  2. 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.

Steal forscoping any tool before writing the first prompt — use it to cut scope ruthlessly for internal builds
CTA Breakdown

How they asked for the click.

VERBAL ASK
35:29link
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.

Storyboard

Visual structure at a glance.

talking-head open
hooktalking-head open00:02
buildermethods.com site
cta-previewbuildermethods.com site01:27
Superconductor multi-project view
setupSuperconductor multi-project view02:28
PRD Creator skill — initial prompt
valuePRD Creator skill — initial prompt03:22
internal vs SaaS concept slide
valueinternal vs SaaS concept slide06:30
PRD HTML + milestones folder
valuePRD HTML + milestones folder12:22
milestone prompt.md
valuemilestone prompt.md14:59
plan mode execution in Claude Code
valueplan mode execution in Claude Code15:52
app Home screen (milestone 1 done)
demoapp Home screen (milestone 1 done)22:15
milestone 2 prompt.md in Claude Code
valuemilestone 2 prompt.md in Claude Code26:45
milestone log with Contacts patterns
valuemilestone log with Contacts patterns29:27
Simple CRM app with Home/Contacts/Deals nav
demoSimple CRM app with Home/Contacts/Deals nav32:07
Claude editing navigation to set Deals as home
demoClaude editing navigation to set Deals as home34:51
what it should and should not do — closing slide
ctawhat it should and should not do — closing slide35:36
Frame Gallery

Visual moments.

Chat about this