My 6-Stage AI Vibe Coding Workflow (How a Marketer Builds Real Apps)

Hey, this is Depesh Mandalia, and one of the things I've been asked about a lot when it comes to AI and developing apps is, what does my vibe coding workflow and architecture look like? So, I've been vibe coding with AI since '22, since ChatGPT kind of really hit the mainstream, and some of the things I've learned have changed over the years. And in fact, I would say every 3 to 6 months, There's always something new to consider. It could be a new app or new methodology. And also the AI is getting more intelligent. It can take on more work as well. But what I wanna show you today is how I set up my workflow for pretty much every app I build. So I build apps for myself. I build apps for clients as well. And the workflow that I've got set up is pretty much the same for all of them. Now, when I kind of started working with ChatGPT, I was asking ChatGPT for the code, and then I would go into WordPress and drop the code into a WordPress plugin, and that's how I would develop my apps. It was very archaic. It was really the only thing I knew because I'd been working with WordPress blogs for 10, 15 years, so I kind of knew how to set up plugins. But then as AI advanced, and in particular I'd probably say for me things changed when Lovable came out. So Lovable When it came out in, I think maybe '24, back end of 2024, it was the first time where I realized I could kind of do a ton of things without needing so many steps. So with WordPress, I would take the code from ChatGPT, I put it into an app, I would test it, et cetera, and then kind of publish it. And it was very time consuming. Testing took a lot of time as well. So with Lovable, what I found was you could give it a prompt. It could host your app in testing and actually didn't really need much. But then I quickly grew out of it and I realized if that's the route you take and you're kind of relying on an app like Lovable to just do your entire app development, it can only take you so far, especially when in 2024 I started to build public-facing apps, apps which would need login security, Meta ad connections, and things like that. And then you realize that these kind of one-stop shops are not very— I wouldn't say not very secure. They can be secured, but to make them secure, you need to really know what you're doing. And I had to learn that fast as well. And then I realized there's actually a better way of developing these apps using a better architecture. So 2025, I started to build that better architecture, and that's what I want to show you today. So I've been using this for probably 18 months now, and generally it hasn't changed At some point, maybe the apps will change. So, you know, Claude can get replaced with something else, or Replit, or, you know, any of these apps can be replaced. But what I want you to take away from today is the actual process and the architecture. Which app you use is entirely up to you. But these 6 stages are super important. So that's what I would want you to focus on is how I set up these 6 stages for success. And really the impact that the project memory and knowledge layer has on the entire success of this as well. So let me get into how I get started. Now, when it comes to ideation, I would recommend that you don't just rely on one AI to do that for you. So what I mean by that is when you— let's say Claude. I'll work with Claude and I'll start discussing ideas and say, Here's what I want to do, and we'll just start to have a conversation. And it needs to be a normal conversation. You don't have to think technical. That's what the AI is for. Start the conversation just by asking the question, I want to do this. And you can say, what do you think? How can I build it? How can I move things forward? And things like that. So that's where the ideas are sparked from. So every idea for me just starts with a conversation. And that conversation could be 5 or 10 minutes. It could sometimes be an hour because sometimes I don't really know what I want. I remember I was building an app for a local charity and they came here, gave me a kind of broad brief that we want this kind of game, we want it for kids, we want to entice them into learning about history and things like that. And, you know, it's a program that the charity funded, but they didn't really give me too much. And it took me probably 30, 40 minutes to get to a stage where I understood what could be done. And then I could push back and say, well, actually, why don't we do it like this? And all the while we're having back and forth conversations. The AI is also understanding what I want and able to come up with better ideas as well. So the brainstorming part of it, it should be— you shouldn't feel the pressure to go and do the research. Like, this is a huge thing. 5, 6 years ago, you'd go into Google, do your research, watch videos on YouTube, land on blogs or groups, and start kind of learning from it. Then you might engage a developer. I've done this process. It's very very hard and time-consuming. I've gone into Upwork, I've found 10 or 20 developers, pushed the brief out there, they've come back, we'll agree on a brief, and then like 6 weeks later, I realized that I didn't explain it properly to them, and therefore what they've delivered back to me isn't really what I wanted. AI just resolves that so much faster. So a deep conversation with that goes a long way. But what I also do is, so Claude is my AI of choice. Previously it was ChatGPT. What that is for you, it doesn't matter, right? I'll just leave that to you. But I also use an app called Manus alongside that as well. So what Manus does is it has right now better web browsing capabilities, um, I think, than Claude. There are other apps out there as well. I mean, you can use, um, Hermes and others. And some people do use Claude with Claude Code and kind of build mini apps to do this as well. So the reason I use 2 AIs is because I want the ideation to be quite broad. And it's like if you speak to one developer and you're like, I want this app and I want it to do this, then you speak to another developer, sometimes they have different ideas. It might not be better, might be better, but you can bring the 2 together and come up with a really good brief. So I I usually start with Claude, and then once I've got to a stage, I'll then take that to Manus and say, here's an idea. So we've already spoke, we've already chatted for 20 to 30 minutes with Claude, and then I might take that to Manus and copy and paste and say, here's where we're at. What do you think we could do next? How could we make this better? And often Manus will go on and do additional research and sometimes even come up with some mockups on its own as well. So that's my start place. I want to make sure that I've got a well-rounded idea before I take it into, okay, turn this into a plan. That's where stage 2 comes in. So stage 1 is just jamming on the ideas, coming up with different ways to solve the problem, and for me to better understand the problem. So that's step 1. Now, step 2 is the PRD. This is the specification. PRD stands for Product Requirements Definition or Document. And what this does is it takes an idea and formalizes it into a plan. So effectively, if you were talking about an agency, like a development agency, this would be like the researcher and the senior researcher, I guess, identifying things and the project manager working with you on what needs to be done. This is now the technical project manager writing down the specs, like what exactly do you want and how should it be delivered. If you really dedicate the time to this, it will save you so much expense later on. And that expense is money, it's also time, and it's also resource. So, you know, when you look at anything that you work on, you know, you only have, uh, those, those things to play with, which is time, resource, and money. And essentially what we end up doing is we have to sacrifice something often In order to achieve the goal we want. So if I put that in for time, we put in that for money, and we put in that for resource. So generally, when you're project managing— because I, believe it or not, I'm a qualified project manager. I qualified in 2005, I think. Didn't enjoy it. It wasn't the career path for me. Here I am showing YouTube videos about vibe coding. When it comes to time and resource and money, often as a project manager, you're caught in between, I would say, a rock and a hard place when it comes to deciding on priorities. So often one of these loses out. So often you have, let's say you've got money and resource, you've got all the people and all the money. But the time is really, really limited, and therefore you have to think differently. Or maybe you've got time and resource, but you don't really have money, so you have to think really efficiently about how you use your resources, what you don't have, which is money. And then some people have time and money and no resources, so then there's a gap there. So when you're project managing, you have to think about all these things as you kind of go through. It's a big part of what the PRD is there for as well. For example, you don't have infinite budget, or you might not have infinite budget, and therefore, you might need to think about things differently. They all need to be discussed and scoped, or you might not have infinite time, you might not have infinite resources. They're all things that go into the spec. And what I end up doing is making sure at this stage, every component that's involved is considered. Take, for example, I've built the most recent app I've built for myself is called Agent.com. And within that, we connect to Meta and we do it in a way that protects our own relationship with Meta and also protects our users as well. And this is based on years of experience of doing this. I want to make sure that that's 100% locked down in the PRD. So I'm making sure that's in there. So when I've gone through the ideation phase, I'm not necessarily just pushing a broad idea into the PRD. When it comes into the PRD, I'm still finessing what goes into that. So it's not like, here's my idea, turn it into a PRD. I don't approach the AI like that. What I'm asking for is, here's the idea, I want to build a PRD. Let's consider all the other things that we need to get in place before we can structure that in a way where the PRD will consider everything. So we're talking about API connections for Agent Calm. There are multiple APIs involved for analyzing web pages, for taking screenshots, for the Meta API and others as well. We want all of those included so that all the coding, before the coding actually starts, it has a broad idea of what it needs to create as well. And one of the biggest things that your PRD needs to pull out is what is the current state of where you are? Where do you want to be and what's the gap? Because essentially what you're coding for is the gap. So the current state is, let's say for me, I have an AI app which I developed a few years ago. I want to turn it agentic. So I want to turn it into a multi-agent system so the user has to do less work. So that was the current and future. And then the gap is, okay, how do I get there? What's missing right now? And what needs developing and things like that. So once the PRD is created, I'm reading that, and I'd be honest, I don't fully understand all the time what it is actually saying, but I want to make sure it looks about right. And I'm saying that as someone who is not a developer, coder, things like that right now. I'm a marketer, I'm a business owner, but I'm also a vibe coder. And I will also talk about vibe coding because There is a misconception that you just jump into AI and then you just ask it to do stuff and it's amazing. It doesn't work like that in practice. If you want an app that's reliable and trustworthy, especially, that needs a bit of work from you to define what you need and then to test it and make sure it does exactly what you need as well. So the PRD is so, so important. Now, once I have the PRD document, the next part of it is the design. So I'm going to show you what an example PRD looks like. So this is something which I built some months ago. It's called an LNA, Lead Nurture Agent. And the idea is I wanted to build this on top of Manus. By the way, it's progressed and it's no longer needed Manus. I built into my own CRM. But back then it was a full document on exactly what needs doing and how it needs to be done. And there's I'm not going to show you the whole document because it's private and, you know, maybe you slow down and take screenshots. I don't really care because it's been superseded. But the key thing about this is it's an in-depth document that captured exactly what I wanted from a lead nurture system. Now bear in mind, about 4, 5 years ago, I developed— probably 4 years ago, I developed quite an advanced lead nurture application using Zapier. So within Zapier, it would, you know, take emails from ads, landing pages, things like that. And then it will process it into a flow using AI. So for example, if an email came in, we could go and plug that into other APIs and Zapier can understand, is this a business owner? Are they on LinkedIn? Can we find them online? Things like that. So we're enriching the data, check within the CRM, which at the time was ActiveCampaign. Does that user already exist in our system? So loads of connections. Then it would pass that to the AI and say, what should we do next? So if you look at the difference between coding and kind of open-based interpretation, that's where the AI is really good. It's just interpreting stuff. So if I give all of that information to AI, it's the same as what I would have done 7 or 8 years ago, where I'd have someone as, as a human looking at nurturing leads. That human would look at the same data and make the same decisions, but now I have AI doing that, so I don't need a human. So in the lead nurture flow, the AI can determine what action should take next. And, and for example, is this a good quality lead? Could we maybe, you know, give them a freebie? Are they maybe high value and just give them a call? Maybe they're ready for a webinar. Maybe it's a low-ticket offer so that AI can make all of those decisions and then make a call on what the next step should be. But the next step is already defined. So like, for example, in the backend for this, what we've actually developed is I have a working system of live offers so that AI can never make up an offer because that would be a disaster. It's like, hey, get book a call for $10. It can't do that because if it decides this is a high-ticket client, we should give it a high-ticket offer, or give them a high-ticket offer. It will go into the live offers database, and there might be 5 or 6 offers running at any given time, and it can identify what the offer is. Is it suitable? Because the offer also has, um, an avatar attached. So this kind of avatar is suitable for this offer, etc. And then it can propose that and push that back into the flow. So This was all built through Zapier. It was expensive. So if you've run Zapier before, um, with, with, at least for me, with so many hooks and connections, it was super expensive. I'm talking about at peak, this was costing maybe, I don't know, maybe even a grand, $1,000 a month. So we're talking about the AI plus the Zapier costs. Now, if you look at that in context of hiring a human, Hands down, it's cheaper. Like a human doing this would be at least $2,000-$3,000 a month. And then, you know, percent of sales and all that kind of stuff to get the call booked or to sell online. So it's still cheaper, but I'm now running it probably. I'm just trying to think. It doesn't cost much. So like this whole flow now runs in my own app that I built, and that app is actually within, you know, front end codified in Replit, which I'll go back and show. And the backend is through Claude. So this whole system now, it doesn't— I don't know, maybe $5 to $50 a month. It really depends on volume and what we're doing in marketing. That's a huge difference. Like, yes, $1,000 is cheaper than hiring human. Let's average it out. $25 a month to run this entire system on the new way that I built it. It's ridiculously cheap. Like, I don't even need to worry about break-even cost, all that kind of stuff. It's just super cheap. So that flow was built through this lead nurture process— sorry, this PRD process for the lead nurture agent. And this document detailed every single thing I needed. Once I had that, I took it to the design stage. So where I see a lot of people failing is they'll take— some people do do a PRD, like a lot of people will read up online and say, all right, I understand I need a PRD, and go to AI and ask for it. It's not very hard. I would say start with the front-end design first. It makes such a difference. Like, if all you do is take your PRD document— if I took this document to AI and said, look, I want to build it— I've done it before. I put it into Replit and it will build it, but it's terrible. And the reason I say it's terrible is what AI uses as its reference for design is very generic. And if you want something that I guess doesn't look AI, but also looks on brand and kind of more you, then you have to go through the design phase. So like this, for example, for me, you know, this is my live website on bpmmethod.co. This is my brand. Like everything here, I've designed it and done it through Claude Design, and it's very deliberate. Now, if I'd not done that step, it would look very different and it would take me a long time to fix it up. And I'm telling this From experience, so don't skip the design phase. Now I use Claude Design. You can use Lovable. You can even use Replit as a front-end designer. You there's lots of apps. You can even use Canva to design landing pages, ChatGPT, whatever. My preference is Claude Design. The reason is not only can I come up with concepts very quickly, I can progress them quite fast and then download code. Ready-made. So for example, this whole design stage is not just about the visual. I can then take that design and push it into the build phase as actual HTML and code and instructions and things like that. So for example, if I show you this here, this is a chat for agent.com. Now there's lots of different screens that we've designed and worked on and done section by section. This is how we built up our audit capabilities. So for example, What I have done here is taken how we produce agency audits, given Claude Code some examples, so spreadsheets and PDFs. Here's what we sent to clients. Here's how we produced it. Here's the information we have. And then through Claude Design, which is now called Artifacts inside Claude, we then turn that into a design. So this is a mockup. It's not real data. a deep audit, there's a Core 4 scorecard. If you follow the BPM method, that will make sense. There's like a baseline audit. These are different audits that my live app can deliver to a user, but it's been designed in a way where I wanted to make sure the front end, what the user sees, is as close to what I want as possible before the code goes in. So, for example, Here we have this thing called the Creative Matrix. We can score the ads. So these are kind of top performers. We can give some information why they win, things like that. It's so much easier to do this in design and before the data comes in. So like, I know what I want it to look like. I can then ask it, or I can just kind of click share and I can download a PDF or HTML with actual code in it. And there's different formats. And then I can then send that to Claude Code or to Replit and say, Here's what I want you to deliver in terms of the user interface. Go and plug the backend in. I don't know how the backend code works. I know what I want it to look like in the frontend. So that becomes a very easy way for me to define it. Again, if I just went straight to the build stage and let it come up with an audit template based on what I asked for, it wouldn't be very good, and it would take me a long time to fix up. So this, again, is saving time and improving quality as well. So design stage, really, really important. Save time later on by getting it right first. Then we have the build stage. So this is— there's different ways of doing it. The way I've done it here is I use Replit as my front-end code. So this is Replit here. And then I use Claude Code as my backend code. There are many reasons I do this. A lot of it is because I work with external APIs. I have security and database and things to consider. Replit is really good at front-end and high-level coding. It can obviously do back-end code, but tools like Replit, Lovable, and others, I feel, are kind of more created for people who are not going deep in their apps. I'm sure people that work there would firmly disagree, and they'll come up with examples of people who have maybe made hundreds of thousands or millions with their apps. But the fact is, These coding apps, and I'm telling you this from someone who's worked deeply with them, are great up to a point. And there's the reason I use 2 of these, and Claude especially for detailed and backend work, is again, it's kind of linked to why I'm using 2 AIs for each step. So for research, Claude and Manus, I get Claude to write my PRDs, and then I get ChatGPT to review it. design work's done through Claude because I can visually check. But these steps here have double AIs involved because I don't often really understand what it's saying when it says, use this coding architecture or use this framework and things like that. Okay, that doesn't really mean much to me. So I might take the PRD from Claude and say to ChatGPT, hey, I have a PRD. Can you just double-check it? This is what I want it to do and things. Is there anything you would consider? Then I can pass it back to Claude and say, hey, I had a look and here's some feedback. So this is a really good way of overcoming the tech barrier as well. And I do the same here as well because I found, at least from my experience, Claude is far better at connecting code and backend pieces than Replit alone. Now Replit uses multiple AIs. Replit's a wrapper. So Replit's like, for example, um, if you think about WordPress, WordPress is a wrapper for an HTML file. HTML is like what is delivered on the internet. So Claude is kind of like writing the HTML directly. Replit is like having WordPress. There's a case for both, but if you want to be advanced and kind of do more clever things and more connectivity and more reliability and security and all those things, I would recommend relying more on Claude. So any code that I'm building that has any kind of security, any external factor login, all that kind of stuff, I would always include Claude in that. If it's like an internal app and it's not really— I'm not worried about security and things like that, then Replit's kind of okay. So that said, you could build your entire app in Replit. I don't do that. I use external apps to give me security and backup and things. So the first external app that I always rely on is Supabase. That's my database. So anything requiring data, users tracking, anything like that goes into Supabase. And then I use GitHub for storing code and to be able to version that code. So what that means is if anything goes wrong, I can kind of reverse that change. So things do go wrong and reversals may need to happen. Yes, you can do it in Replit and others, but it's so much cleaner to do it in GitHub. Also, the advantage of GitHub, because I do external builds for clients, is that once it's built and if it's part of the agreement, I can take that code from GitHub and just give that to the client and publish it and build it for them as well. But they can then own the code. And it's so much cleaner to do it through GitHub because I don't have to then worry about sharing my entire architecture, and they don't need to worry about all the complexity in most cases. I can then put that through GitHub. And it also means that when it comes to testing and launching, GitHub is just such a central location to be able to do all of that as well. Generally, Replit for frontend, Claude for backend. I'm using Supabase for database and GitHub for kind of managing code and code branches and things like that. And what that means is, let's say you've got your main source code, you can take a branch of that and then do some coding with that. And if it doesn't work, you can just kill it and it doesn't impact the main code. If it does work, then you put that back into your main code. So that's really a big advantage of using GitHub. Now, the other part of this is testing. One of the tools I use, which I've never mentioned before, and there are others you could maybe consider, is this tool called Codo. I think that's how you pronounce it. What that does is it interacts with GitHub. Now, if you imagine all the code that Claude and Replit are building for me gets stored into GitHub, and once it's in GitHub, I have this app attached to GitHub which checks all the code for errors, gaps, misunderstandings. Because even with this layer, sometimes let's say you fix something here, it might break something somewhere else. And you don't want to catch that testing on production, or you don't want to catch on production. You don't want to catch that or miss that. So what Codo does is it says, okay, this particular new piece of code, this new branch, I can see what Claude and Replit have done because it will put the code in and it will show what's been changed. I'm just going to go and check a few other things while I'm here. And I can't tell you how many times Kodo has caught things which Claude and Replit have missed. So what ends up happening is I then have a loop where the code is published to GitHub, Kodo is then called, and then that goes back to Claude or Replit, whichever one I'm working on, To double-check. Now, some of those are things that are not relevant because it will change the architecture. So Claude will say, okay, I understand what Kodo is saying, but we've done it this way because— or it'll say, that's a really good catch, I didn't consider it. Like, Claude has no feelings. It doesn't get butthurt if Kodo comes back and says, hey, you made a mistake, which just means they're just working on facts. So it's a real convenient way of testing. The other thing I would say is Replit is one of the best at doing its self-testing as well. And Claude's gotten better. It's still got some gaps. Both of these do their own testing, but often they will miss the bigger picture. And to test, especially in an app like Agent Calm, which has tens of thousands of lines of code, is very hard to test everything at the same time. So I kind of have a triple layer. Replit tests its code. Claude tests its own. And Codo tests everything. So this just makes sure that when I'm building and testing, there are multiple levels to make sure that things are caught early as well. Then at this stage, we also publish into staging. What staging does is it's a copy of whatever is live, but not live. That's essentially it. So with staging, that's where I'm testing it. So all these stages, the AI has already coded, tested, and done its thing. by this stage, Codo is happy, and now GitHub's published it to staging. That's where I then test. And the cool thing is I've instructed these that for every build, write me out a user test. What do I need to do? Just step by step, tell me. So that when I come into here, I know exactly what I need to test. So it might say, hey, we've developed this new audit. In order to test it, step 1, Select a project. Step 2, make sure your Meta account is selected. Step 3, type this into the chat prompt. Step 4, give it a minute for it to produce this report. Step 5, check the report and the data. So it will give me a step-by-step flow. So I don't need to remember what to do, and also I don't need to worry about missing something out just based on what's been coded. Once that's done, Then we're ready to publish. Now, I use an app called Railway. Railway is my hosting app. So, this is kind of what hosts the staging server as well as the live, and that's integrated with GitHub as well. So, you'll see these 3 critical stages. GitHub is like the central source of truth, and it's holding all the code. If there are problems here, I'll go back and get those fixed. But at this stage, once it hits production, It will go live. And again, I'm doing the same testing I did here on live just to make sure everything's working as well. And the good thing about Railway is it's, it's fast, it's reliable, and it's very low cost. Um, I can't remember what plan I'm on, but it's not really that much. And you know, I've got lots of integrations and APIs and apps that I'm using alongside my apps, and it just, everything just works. It's easy to set up. It was fast to set the domain connections and things like that. The whole thing just becomes super easy to flow as well. So even though I've spent about 30 minutes explaining this, this is actually a real simple workflow. And I'm telling you this as someone who took the long way around 5 years ago to kind of figure this out, or, you know, have— I've worked with developers, I've worked with all these different AI apps as well. This is the most efficient way I've found. And, you know, if you look at costs to develop all this, The cost will be high initially because you're learning as well. You're learning what becomes a good brief, how to, you know, provide good feedback as well. Take design, for example. Sometimes what I'll do is I'll come into this and I'll go into inspect and say, you know, change that to leads per month like that. And it's just easy for me to just feedback and say, hey, I've made a few changes, um, implement this. So I can then kind of go back to the AI and it will make those changes faster. You can also do edit straight here. Um, you know, you can come in and change, um, stuff. So if you want to change the copy, some of the design elements, you can do all that here as well. But there's, you know, there's different ways of feeding back, but you get more efficient yourself at doing that as well. So that enables you to start to cost save as you go. Subscription-wise, I think Claude, I'm on a $100 a month plan. I often go over because I'm doing a lot of development. Replit, I think $50 a month plan. Supabase, $10 per database. GitHub is free. I don't know why. Coda, I think I'm on the $100 a month plan. Railway, I think it's like $50 or something. So this is— and Manus is about $100 a month. But this is quite an advanced setup. This is because I do a lot of app development. If you're doing it for yourself, you could get away with not having Manus here, not having ChatGPT, which I think I pay $30 a month, and maybe even not having Supabase to start with, maybe not even GitHub. You know, if you host on Replit, which you can do as well, you can cut out a lot of these steps. But if you're looking to actually sell an app with access, with payments and things like that, you need security and you need to really consider how you're present in that as secure code as well. And the other part of this that I will also mention, which I think a lot of— because I watch some of these YouTube videos and a lot of people bypass this— is like, here's the process I use. Project memory and the knowledge layer. This is so important. So for example, there's a file called Claude.md, which both Replit and Claude use, which contains rules and, you know, things to do, things to not do. Even something as simple as I can't remember how I worded it, but it's like, you know, you're coding for Deepesh. He's not a developer. He's not a coder. Essentially, he's a noob. So don't go too technical. Don't over-explain things as well. Be, you know, be to the point, but also don't expect that he understands technical terms. So like, even those things make a huge difference so that when the AI is speaking to me in the chat and saying, hey, this is my feedback, here's what you should do. I understand what it says. So there are things that you learn over time, and it becomes easier for you to observe. And also, you can put in there, here's my workflow. That's an important part of it as well. So it understands, like, for example, when I've built Agent Calm, it knows that there's multiple AI involved with this so that it can kind of make decisions as well. So, for example, if it's like a simple UI change, it might say, well, it's better just to do that in Replit. Or it might say, I'll do it and then I'll update Replit's notes. And that's another thing. We have what's called a repo for docs. So this docs folder is accessible by all the AI. It has living documentation. It has PRD segments. So the PRD for Agent Calm is huge. It's like 30 pages long. I think it's like, it's massive. But sometimes we pull out segments. So let's say, for example, you know, let's say we're developing this deep audit because not everything was done right from the start. It might pull that out as a segment and store it in there. So, /docs/deepaudit.prd, and all the AIs can talk from the same page. So, they understand what they're supposed to be doing, any decisions on architecture and design, all that kind of stuff is included there. And then all the PRDs, once they're broken down, they feed each of the development layers. So, both the build and the test phase, And all that knowledge is passed back as well. So any decisions, coding changes, anything like that is written back into the project folder or the documents. Like, for example, if we make a decision on a particular scaling strategy and how to connect to Meta and how to interpret that data, a file is created in the docs folder. So, for example, it might be scaling_strategies.prd, and in there contains all my knowledge base and all my Uh, ways of doing things so that when it comes to decision-making, whether I talk to Replit, Claude Code, Codex, it doesn't matter which AI it is, they're all working from the same document. And this makes a huge difference for me to just know that even if like 6 months down the line we decide to change ad strategies, we can go back and look at what we created 6 months ago and update it, edit it, whatever it is as well. So it just becomes so much easier to manage the entire flow. So That's my vibe coding setup. You might have different opinions, you might have done things differently, you might question some of what I've done, and then I welcome that in the comments as well. But this is what I built up over 18 months. It's super reliable, stable, cost-effective, and for me, it's easy and efficient as well. So, there are multiple steps to work on, but at least when I'm building my entire coding flow. This framework is just like the de facto. This is my starting place. Sometimes I may bring in more AI, you know, depending on the complexity of what we're building. Sometimes, you know, at the PRD and build stage, we're working with different APIs and different things that I haven't worked with before. But again, I'm using the same process. Go look up the API documentation, help me understand what's available, what can be done, Maybe this week it's Airtable. You know, I had a request for Agent.com to plug into a new reporting tool called Everflow. I'd never heard of that before. What was it? Something like that. I can't remember. So we're now looking at, you know, how could we integrate that into our app? The AI is doing the research. Maybe it's Manus, maybe it's Claude Code, and then building that into a new PRD to say, okay, we're going to integrate live external reporting into our Meta apps. Meta Ads app. How do we do that? How do we consider that from a user point of view? For example, the latest update I'm working on right now is a Slack integration. It's done, it needs testing. So we're now at the testing stage for that Slack integration. Once that's in and live, then that will go back into the knowledge layer, and then we'll go back into the next update from the PRD. And, you know, even with a live app, once you've got the app fully running, you can still go back to the ideation stage. So, one of the ideas I've got, which I want to share with you, it will need some ideation and research because I want to make sure that what I'm solving next is going to make a big difference for users and also getting user feedback. So, that ideation then builds a new PRD, which might not be 30 pages this time. It could even be 1 or 2 pages. That gets designed, built, tested, and launched. And the entire process just continues for every update as well as a brand new app as well. So I hope that you found that useful. If you've got any questions, let me know, and happy building.