This Planning Method Will Make You A Top 1% AI Builder Overnight

What's the number one skill that you must have to succeed with AI coding? Because most people just hop into fancy tools like cursor and claw code and replet shooting from the hip, hoping, praying that the AI gods will just make their dream come true. But that just leaves you with three things. Broken projects, weeks of life lost, and the endless cycle of constantly rebuilding things from the ground up. Now, as someone that did shoot from the hip and build a 20k a month no code SAS, I can

tell you it's setting you up for unimaginable pain. So, in this video, I'm going to show you the exact framework to avoid that pain altogether and start building apps that are really awesome. And it all starts with the vibe planning pyramid. So, here's our beautiful pyramid. So in our first level, we are trying to establish the foundation. And a good way to think about this is the what and the why. And this is where we're going to plan out what exactly are we building and why

specifically are we building those pieces. Now this would be considered bottomup planning but the benefit is that we are going to prevent a lot of very painful reworks if we take a lot of time to determine what exactly it is that we're going to build and why. So slightly longer setup but a lot quicker and less painful path to getting to the end. So if level one is the what and the why, level two becomes well how and where. So, this is where in this section, we're making sure that all of

these foundations we built are actually going to come to life in the way that we want them to. Now, once we have our what and our why established and our how and our where, we can move to level three, which is actually planning out the build itself. Now, we will get to that section and what I include there at the end of the video. So, make sure you stay for all three of these levels. So we're going to start with level one, the what and the why. And again, this is the

bottom of our pyramid. So let's start with the end in mind. What type of output are we actually looking for in this first planning phase? We want to have a really clear understanding of what we are building and why. What is the coremost problem that's being solved? Who is it for? And what is the actual solution for it? And if all of that is there and in place, how would we know that it's actually successful? Meaning, what is the measurable metric that would tell us, hey, someone's

actually using my app the way I want it to be used? From there, we want a breakdown of all of the key features inside of our app. So, the user stories, the acceptance criteria, how do we know that it's being used effectively and that they're getting the outcome? What do the core UX flows actually look like as someone moves through this thing? And what do the core user journeys actually look like? Meaning, how does someone interact with this thing and make their

way from having this problem all the way through a series of steps to solving that problem? Now, all of these things are tied together because the problem is going to inform the features and the overall user experience. And our user journeys are going to tell us like, well, what does that actually look like? If someone's trying to solve this problem, what does the sequence of events through that experience actually look like? And so all of this gets covered off in our level one foundation.

And by the way, if you want all of those prompts, I have a free course below where I show you how I went through that entire thing and challenged the language models back and forth to end up with a core finished user experience. and feature set. So again, that's free in the description below if you want it. So on a high level, what is it that we really do need to be super dialed in on? Well, first is the core problem that we are actually solving and what other

solutions exist to solve that problem because if we're not super clear on this one, then nothing else is really going to make sense. So I'll give you an example of that. In this project that we were just looking at, I'm creating a tool that's meant to help take all of the different sources of notes that I could possibly have, but synthesize insights out of them because I have a hard time when I'm like reading different books. I'm taking notes on my computer and multiple note-taking apps.

I'm creating prompts. I'm watching YouTube videos. I'm doing all this stuff and a lot of it just goes into a graveyard of notes. So, how can I make sure I'm extracting insights from those things and taking action on them over time? Now, if you were to take that description, you could ask yourself, what is the core problem? Is it that it's difficult for you to capture notes in all the different places that you are? Is it that it's difficult to bring them all together and see what you were

doing at any point in time? Or is it that it's difficult for you to take insights from those things that you can actually do something with? Because depending on which of those three I say is the core problem, my user experience will be widely widely different. If it's the case that I can't actually capture things effectively, well then I'm probably building thirdparty integrations with all of the different note-taking apps I use and trying to merge them together into a single source

of truth. But if it's the case that I'm having a hard time synthesizing that stuff, well then I'm gonna have to build some sort of engine powered by a language model that can actually look at all of the different sources of information and do something with it. So that's why when I say you have to be really clear on the core problem, I mean you have to be very very clear on what exactly is the problem you're solving. So once we've identified that, we've found other solutions to that problem

of truth. But if it's the case that I'm having a hard time synthesizing that stuff, well then I'm gonna have to build some sort of engine powered by a language model that can actually look at all of the different sources of information and do something with it. So that's why when I say you have to be really clear on the core problem, I mean you have to be very very clear on what exactly is the problem you're solving. So once we've identified that, we've found other solutions to that problem

and we know that it's worth solving. Well, how does that manifest in the user experiencing this thing? So when we went through earlier, we had a bunch of different user stories and we had our core UX flow fleshed out in a lot of detail. So for example, for that core like instant note capture, what does a user story look like? Well, as a busy knowledge worker, I want to immediately dump thoughts without navigation or friction so that I can capture my ideas before they vanish. Now, even just

thinking about this line, there's a thousand1 different ways that I could actually do that. Now, similarly for the AI powered reflections, as a user with dozens of scattered notes, I want the app to synthesize themes and restore context so that I can understand what I was thinking without manually rereading everything. Again, 50,000 different ways that you could build this experience as an actual user interface. So that's why we spend a lot of time writing out those

stories but then mapping the user journey which we looked at earlier and then thinking through well what are the real friction points someone might encounter in trying to do that. If I'm the user who has 50,000 different notes and never knows how to extract the meaningful stuff out of them. There's going to be a lot of potential friction points with me using this app. Like I can't run into a problem of it just being the same problem all over again. I have to make sure I overcome that. So,

as part of that problem, we need to make sure all of our features are broken down and prioritized. That list I was showing you, that list was a lot longer when I first started. So, we listed out all potential features like integrating with my Kindle library, but then we categorized them into what must absolutely be there for the MVP. And then we sequenced those into what we wanted to build as that core user experience for the MVP. And then what the success criteria looked like, which

in this case was that 60% of new users get to their first reflection, meaning they've dumped 10 to 15 notes in there and it synthesizes all of them. And so again, thousand foot view for this section. We want to make sure we really understand the problem that we have all of our features broken down and prioritized that those features fit into a really sensible UX flow and series of user journeys through those features so that we know what shape they really have and then how we know that it's

successful. And again, if you want to see videos where we go through all of these things live, I have a free course below where you can see it in more detail if that's what you want. But again, the prompts that I use are for free also in the description below. So again, the next step of this pyramid, if the first step was what are we doing and why, this is the how are we doing it and where should things go. So one of the best places to start is with the actual

successful. And again, if you want to see videos where we go through all of these things live, I have a free course below where you can see it in more detail if that's what you want. But again, the prompts that I use are for free also in the description below. So again, the next step of this pyramid, if the first step was what are we doing and why, this is the how are we doing it and where should things go. So one of the best places to start is with the actual

tech stack. Now again, I have a prompt that you can get below and there's a video where I go through how we're doing this where we give all of our refined UX and product requirements and then we ask it to map this onto a tech stack. And so what this thing does is it goes through and it either takes in our recommendations for tech and if there's a piece of tech that's missing, it will ask us to make decisions and it will give us suggestions. So, for example, in

tech stack. Now again, I have a prompt that you can get below and there's a video where I go through how we're doing this where we give all of our refined UX and product requirements and then we ask it to map this onto a tech stack. And so what this thing does is it goes through and it either takes in our recommendations for tech and if there's a piece of tech that's missing, it will ask us to make decisions and it will give us suggestions. So, for example, in

the backend architecture of this app, do we want a full backend with a fast API? There's a database, there's worker cues. Do we want a very minimal proxy where the API in the backend is really just there to forward requests to the language model, but everything's living on the user's device? Or do we want to not even have a backend and just store the API key in secure storage and just send the requests directly through? Another example, how do we want to actually handle the styling in the app?

Do we want to have React Native Stylesheets with our own manual theme system? Do we want to use a tool like Native Base, which is going to be a little bit heavier, but a lot of it's built for you already. Do we want to use some other design UX library? Like, what do you want to do exactly? Because this is going to influence how we choose to build things. We then ask it to specifically ask us if it wants to override any of the decisions that we've made. And then once that's all done and

you've gone back and forth through a few cycles, you're going to get out the other side a detailed piece by piece specification for what the tech needs to be. So everything from the front end to the navigation to how state is going to be managed to form systems, how the UI and styling is going to be handled, what the backend proxy in this case needs to look like. All of that stuff is going to be listed out for us. And again, we have this opportunity to go back and forth if

we need to. But then all we need to do is pass this into our next stage. So what does that mean? What are all of the data models that we're going to have? So for example, in this note-taking app, I need to store reflections. I need to store notes. I need to store maybe chats if I have chats down the line. All of those are entities that need to have data models behind them and relationships to other pieces of our data. So we need to make sure we have that entirely ironed out. We need to

make sure that we understand how the backend is going to function. What are all of the endpoints that we have? What services get invoked when those endpoints are called? What data do they expect in? What data do they send out? How are we going to actually develop this thing and deploy it if we want to put it in other people's hands? And then what I like to leave for last is actually setting up and configuring the user authentication and the permissions and all of that stuff. So how do we do

that? So to be clear, this is exactly how we do this in that level one. We're outlining all of the features and the user experience. We then go through and we define beforehand what the tech stack is going to look like and we get our project configured to be ready to build with that stack. We then take all of these features and we turn them into epics. Again, I have an entire video where I show exactly how to do that to go from features to epics, which I will

that? So to be clear, this is exactly how we do this in that level one. We're outlining all of the features and the user experience. We then go through and we define beforehand what the tech stack is going to look like and we get our project configured to be ready to build with that stack. We then take all of these features and we turn them into epics. Again, I have an entire video where I show exactly how to do that to go from features to epics, which I will

link above this if you want to see how that's done. From there, what we do is we pass each epic into a specdriven development tool like GitHub spec kit, which does all of the heavy lifting in creating the data models and the schema, creating the actual API contracts, configuring the deployment and environment strategy, setting up all of the data models and the O and permission. Again, all based on all of that work we did in the earlier stage. So what we're going to have out the

other side if we're using a specd driven development tool is a really concrete plan that is mostly ready to be executed. So it has all of the core UX and feature specifications. It has all of the backend data models, API contracts, service layers, all of that specified already. And so then we just need to make sure we execute building it the right way. So how do we do that? Well, we need one epic to make sure our development environment and all of our tech stack is properly set up and

configured in our package file so that it's going to actually use that. And then we want to make sure we go through and we start executing these things epic by epic. Meaning, we're going to look at each contained piece of the app and then step into all of the different stories within it and execute them one at a time in order. Then as it completes each of those stories and epics, we want to go in with a bit of manual testing to make sure that it's actually working as

intended, make those small tweaks, and then finally put actual testing workflows in place so that we don't break this thing in later changes. So again, level three, we're making sure that everything that went into that level one and level two text stack decision is actually being codified and merged into our development plan. Once that's in place, it's just a matter of using a spec driven development tool to move through and build the thing. So that's it, guys. The number one skill

you need if you want to actually succeed is planning systematically. I used to not do this. I used to hate planning. Now I won't touch even a basic project without it. So we start with our foundations, what we are building and why. Then the architecture, how we're going to actually build that and where things will live and where they interact. And last, we plan the build order. So like I said, I have a course that was just released for free in the group below where we actually go through

this in detail for a real project. So remember, you're not losing time planning, you are buying back weeks of your life. Now, if you want to skip the free course and just see a light version of us running this process, I will link a video at the end where I go through this on my YouTube channel. So, plan right or build twice. Choice is yours. That is it for this video. I will see you in the next