How I Build Apps With Claude (My System)

[00:00:00]Let me know if this sounds familiar. You open up Cloud Code with an idea and for the first hour it feels like you have a superpower. Features are appearing, pages are being built. I mean, you're feeling faster than ever before. But then, as you keep building features, you later come to know that the project is just falling apart. Claude ends up building tiny little projects inside your application instead of using a global architecture. It duplicates code and it doesn't know how to reuse things that already built in the past. You hit your session limits and you reach your context window constantly and eventually you're looking at an app that kind of works, but deep down you know it's just an illusion and you probably don't even trust it yourself. You don't even know if the architecture is actually good.

[00:00:43]You don't know what's going to happen when real users start touching your application. I mean, I don't think you're even ready to start accepting money from customers. So that's who this video is for. web developers who want to build production grade web applications using the power of AI cloud code something you can finally launch something you can sell confidently knowing that every single line of code was built to production and I want to make one thing very clear before we jump into this there are thousands of videos on YouTube that talk about how to vibe code using cloud code this is not that video most of these vibe coding tutorials show you the finished product that already has all the problems we just discussed But none of them give you a reliable workflow, something that has been battle tested to work every single time. And so in this video, I'm going to be talking about my Claude code system, the exact way I code using AI. It's the same system that I use to build over 1,200 plus production features in my own SAS company only using the power of AI.

[00:01:44]And I call this guardrail coding. And this is not the video that has a super in-depth how to set up the entire thing step-by-step sort of guide. I will be uploading a free course on YouTube that will show you how to do all of this yourself. But in this video, I want to show you what is guardrail coding, how it works, and how it solves some of the most common AI developer problems today.

[00:02:06]For example, AI losing context, AI hallucinating, buggy code, insecure code, code that you simply don't trust, or ways to never hit your session or context window ever again. It's a system that will work regardless if the LLM changes or you use a different tool. It does not matter. The same system will work anywhere. And the reason is simple.

[00:02:25]The entire architectural guardrail works on a predictable system. It's mine and my team's years of expertise, trial and error, and months spent to get this together. And I know it works because I have built my own products using the exact same system. Now, I'm not saying that this is the only or the best way, but what I am saying is that this is the AI system that I use to build production-grade applications using cloud code. They look great and I'm confident enough to sell these applications to real businesses. So, here's what normally happens. You start a fresh session. Claude has plenty of context window available so it can start from scratch. But as you work, this window will get eaten up. This is just how AI works. your conversation, the error messages, file history, everything is added into that context window. And so that context is the most important thing when you're building with AI. And so what most people try to do is they write documentation in order to get the app to be built the way they want in order to instruct Claude or any AI agent to build in a specific way. Cloud.md is the first thing to start with. They write down the project structure, folder structure, what rules to follow, and also where to put things. And most people create a docs folder that has all the architectural files explaining how things work in the app. So if AI ever needs to read something, it can just simply pull it through that page. And it sounds reasonable, but that creates another problem. Claudpull use its context window with all of these documentation files. And so you end up burning through your session window before Claude even has a chance to implement the changes you just planned.

[00:03:57]It then starts to compact conversations, which means 40 to 60% of all of your conversation history, the planning features, the documentation you wrote is going to need to be plugged into the next context window. And that's when the quality starts to drop. And the funny part is bad AI generated code rarely announces itself as bad code. You have to have expertise in order to actually find this. Now you're stuck. You're trying to figure out how to fix all of this stuff. And so you try to prompt more. Claude created the problem. You ask claw to fix it itself cuz you're not going to find it anytime soon. And someone mentioned this to me earlier. It sort of feels like you're driving a car in the darkness. You know you're getting somewhere but you don't actually know if you're at the end of the tunnel. You don't even know if you're going to get there in the first place. And so what you've done is you've just written more code to fix bad code. And what people fail to realize is that Claude builds on patterns, not context. So let me ask you this. If you follow incorrect patterns in your codebase, what is AI going to build next? You see, right now there are two ways to build apps using AI. And this is usually what's taught online.

[00:05:02]The first one is vibe coding. You explain what you want in plain English and you describe the feature to Claude and Claude will build it out. You're obviously going to need to stack different pieces on top of this. Things like don't forget to authenticate. Make sure permissions are checked first. But regardless, the thing that Vibe coding sells is speed and a low barrier of entry. That means as long as you understand English, you can vibe code anything. But a big drawback of vibe coding is that the app will never be secure. That means every prompt you make, you have to instruct AI to follow authentication to follow a feature gate system. And every single security measure you want to put in place, you got to put in place for every feature.

[00:05:38]So from day one, when you created the project, you also added an expiration date. Now imagine you're going to add 50 new features to this application. All you're doing is you're building 50 tiny little apps inside this huge folder. And so the next time you intend to reuse something that was technically already built because there's 50 different versions of it, Claude is not going to know exactly what to use. And the second method is agentic coding. This is where you be the architect. You design everything. You make the plan. You give the architectural support and you tell AI to follow your instructions. This means you'll have to come up with all the modules, the different functions, the different pages, components. You got to do all the planning yourself. And one thing I can say from all of this is if I had to sit and think about 1,200 features by myself and think of every single module, function, component, element, design, structure, architectural stuff, authentication, feature gate, rate limiting. If I had to think about all of this, I would have probably not built my product for the next 2 years. I mean even if you tried to build two features per day to production that would take you close to two years. Not everybody has that level of expertise because expertise comes with time. You need to see things. You need to be in the ring in order to understand how to fight. So VIP coding teaches you to build a broken demo and agentic coding requires you to be an expert. And so it's insanely slow. And so that's why I hate vibe coding. I'm not here to build something that will stop 2 months from now. I want to build something into the future. I can add I want to add as many features as I can possibly think and so while I was building my own SAS product which is funai uh which is basically Mochi I created a system called guardrail coding and I've been using it since and it's helping me a ton. So then the immediate next question becomes how does the architectural guardrail actually work?

[00:07:27]So first it's important to understand this is not a single prompt. This is not one solution and it's definitely not this huge architectural documentation folder with every single thing broken down. And let me make this clear. Every month I'm constantly improving the system by either improving the layers or adding more layers on top of what we already have. The architectural guardrail is a stack of multiple systems working together. And each layer solves a different problem. One controls how cloud gets context. Another helps it find the right systems that already exist in your app. Another prevents important parts in your application being built over and over again. and another one gives Claude immediate feedback when the code it builds does not fit the current architecture. So individually these layers do help but when you stack them together it works like a mechanism. So in the next few minutes this is conceptually how every single thing works together and this should help you understand what you need to do if you're trying to figure this out on your own. First the biggest problem we need to solve is context. And to fix this we use a strategy called microcontext injection. I know it's a crazy term, but just stick with me. And the word itself kind of speaks about what it's doing. Microcontext injection, not giving it context before or after Cloud finishes. Or in simpler terms, correct information for the decision it is making right now. So instead of keeping massive pieces of documentation in docs files, small pieces of context will exist throughout the codebase closest to where they should actually be. And these small pieces of context will tell Claude what the system is responsible for, why it exists, what connects to these features, and how it relates to something else or whether it can or cannot be recreated somewhere else. So Claude does not need to load all this information before starting every session. It discovers the relevant context when it reaches relevant parts of the application. But that creates another question. How does Claude know where the relevant system is? So like I mentioned earlier, Claude builds with patterns. The problem is that it does not automatically know the pattern to start with or it doesn't even know what the correct pattern is. Your architecture needs to instruct it. It needs to enforce the right pattern. And if your codebase already has incorrect or inefficient patterns, it will continue to follow the same. And so the architectural guardrail will essentially give that system a source of truth. I want you to remember that word. Get a piece of paper and a pen and write this down. Source of truth architecture. So what's done in guardrail coding is that claude is directed towards source of truth architecture before it even attempts to build. And so the way in which we give claude these instructions is through two strategies SOT keywords and inline injection. SOT keywords just stands for source of truth keywords.

[00:10:06]These keywords along with microcontext injection gives Claude the exact pattern to follow in the app. And now the cherry on top is actually how to enforce Claude to find these SOT keywords. We do this with the help of a GRP script. We enforce Claude to use a GP script to first find different locations in the codebase to know exactly where these words exist. So instead of Claude needing to read through the entire codebase to find all the stuff, it knows exactly which files have the implementation ready to go. If it's three files, it knows it only needs to read these three files. It's the smallest step of action that you can take this very second and drastically decrease your context limits. I don't know by how much, by a ton. I can tell you that because till date, I have never reached my session window. And not just me. Every single person who has tested the architectural guard drill has not hit their session limits as well. In fact, they have dropped their costs from $200 a month to $100 a month. So, you're literally saving more money every month.

[00:11:05]Great. So Claude now knows how to find the correct patterns in your application. But some decisions are too important to just be left as a suggestion. For example, let's say you're building a feature to update project details. Before those updates reach the database, there are a couple questions you need to ask. Does this project belong to them? Have they reached their usage limits or does this include in their plan? Do they have the required permission to perform this action? Or is the data submitted valid?

[00:11:32]I mean, there's so much more. The list keeps going. create limiting but then every feature implementation depends on claude needing to remember these steps it needs to remember and apply these in every single feature and this is where it becomes fragile this is the line that is drawn that distinguishes a senior engineer and someone who's just starting with vibe coding so what the architectural guardrail does is it creates a protected path so instead of rebuilding authentication permissions and all the things we just went through they all exist on a shared layer and because of this they are enforced forced with Claude. Claude does not have an option. Whatever it creates just passes through this protected layer. So Claude still has the freedom. You want to give Claude a little bit more freedom. An instruction says remember to verify the user's permissions. A guardrail says this is a protected operation and so it's automatically moved through a permission system. More importantly, a permission system that was only built once. Now this does not mean that Claude cannot create a bug. I mean senior level engineers still make bugs. That's normal. But what cannot be resolved is a security threat where your entire application is exposed to vulnerabilities. So it's the closest you can get to the best of both worlds. Vibe coding where you can technically type in plain English and behave like a quality assurance engineer mixed with senior level engineering practices that are put in place that enforce the guardrail so that Claude can physically not skip it.

[00:12:55]But here's the important part. What causes Claude to not skip that? What causes Claude to know when it's making a mistake? What if it creates something that violates an existing pattern or a contract? And so this is where the next layer becomes so important when building with Claude. So I want you to imagine this. Imagine your application is sending an echo signal constantly back to Claude. When the implementation of whatever Claude's trying to build fits that echo signals structure, everything connects correctly. But when Claude moves outside that system or the structure, whatever it created just does not match that echo signal, the codebase pushes that back and rejects the code that was just created and that feedback or that echo signal can come from validation, automated checks, linting or other tests you wrote in the app.

[00:13:37]Obviously, the exact implementation might differ based on your text act.

[00:13:40]That does not matter. Regardless, Claude should receive feedback while it is building the feature. and deliberately throwing these errors whenever Claude falls off rails tells it that something went wrong and it gives it the information it needs to fix whatever it just did. I mean, I built it in such a way that I can't even push code to production. I can't like my build would fail if I tried to build that. So, I want you to get that piece of paper and the pen again and write this down. Make mistakes visible and let these mistakes block Claude from handing over a feature that hasn't passed these validation checks. Again, the goal is not to pretend AI can't make mistakes. The goal here is to make it harder and harder for it to hide those mistakes. Now, for the most important part, what connects all these systems? And this is where the cloudMD becomes useful. But most people will make this mistake and they'll think they need to explain every single thing inside this cloud. MD. I mean, my claw.md file is 20 lines long. So, think about the claw.md file sort of like a checklist. It's just instructions that kind of piece everything together and the questions it needs to answer are the principles that are being followed in the app. Always find the source of truth keywords before starting. Follow the existing protected path patterns. And here's another master class on prompting. I call this red green prompting. I'm going to read out the prompt and I would like for you to pause this video and try to guess what's actually happening here. The prompt goes something like this. The app already has most of the things already pre-built.

[00:15:10]You do not need to create new things.

[00:15:14]Always try to update first or use things that have already been built. So go ahead, pause this video and try to understand what might be happening here.

[00:15:23]What exactly are we telling Claude?

[00:15:25]Welcome back. Hopefully you got the right answer. This is what red green prompting is by deliberately misleading Claude to assume that things already exist. It actively tries to find things in the app and use them first. Now, this was just a small example to show you the concept. But when you use red green prompting while you are building features, it is the most powerful thing ever. Now, if there was one thing you took away from this entire video, let it be this. If Claude needs an explanation to understand your app, then you don't have an architectural guardrail in place. And most importantly, you have the best of both worlds. And that's the dream outcome for most developers now, which is to type in plain English, but have the output, the code be so good that you can confidently sell the app to big businesses. Now, I do understand there is a small gap here. The level of expertise and experience you need to create an architectural guard like this can take some time because understanding this system conceptually or through a step-by-step tutorial is completely different from actually implementing it and getting the outcome. You'll still need to decide what becomes a source of truth, what type of text act to use, what should the protected pathway look like, which validation contract you're going to use to send those echo signals to clock. I mean, how do you know if what you've implemented is even correct?

[00:16:46]And obviously those answers change based on your text stack. It changes based on your circumstance and that's why the architectural guardrail can't be the full picture. The end result is what matters. being able to build anything you can imagine. Having you take an application you've been thinking of for quite some time and bringing it to life all using the power of AI. And that's why I created a new community called AI era. And inside AI era, you're going to get the exact architectural guard drill system. The same system that I use every day to build applications like fun.AI, Mochi, and pretty much all the future apps I'll ever build. And what I have in there is a turnkey solution. It is the exact system that you can start today done for you. All you have to do is download it and start implementing. And I also have modules in there that will help you understand each and every single layer in as much detail as you need. And so inside AI era, my focus is to give you implementation guidance. Not only are you going to get the architectural guardrail system itself, the implementation itself so you can start on day one, you also get the weekly coaching calls and guidance you need. You'll get the exact claw.md system, context strategies to help you avoid hitting session limits, the complete prompting framework, the exact workflow of how I build with AI start to finish, code reviews, and technical support. Imagine if you have a question or you're wondering how to start prompting this feature with AI, how to build it, where to start. You can just create a post inside AI era and I will personally respond back with a Loom video. You will stay up to date every single day with the exact architectural guardrail that I am using today. the same guardrail that I'm battle testing with thousands of dollars invested to make sure that it gives me guaranteed code. And I want to point out something.

[00:18:31]Often times, most communities like this always enforce value. Like it's always about value. But what's even more exciting is enjoying the process, being around a community of people who are all driven to accomplish the same thing. And so every month, I'm also planning on doing these vibe coding sessions where we can build real applications. I'm not talking about clones. I'm talking about my ideas and bringing them to life and giving you guys the code base as well.

[00:18:55]You'll get access to the code so you can build your own products on top of them, sell them, pretty much do whatever you want. And to also make this a no-brainer, I have dropped the price to make it insanely affordable. This founders price will end July 25th. And after that, the price will increase. And there's a genuine reason behind this.

[00:19:13]Early members who are joining now are helping us build this community to something even better. Your questions will help improve the architectural guard rail and participation will help shape this community in the future and so the cost to join will always increase. The founders offer is for people who want to join in early and get more value for your dollar. So AI era is for people who want the implementation and the guidance starting today. The support in the entire architectural guardrail built out ready to go.

[00:19:40]Building with AI is going to be the single most valuable skill not just in 2026 but in the years to come. And you, my friend, as a web developer, already have what it takes. All you need is the exact system, the workflow, and everything that drives you towards one goal, which is building cool stuff with AI. So, if you're ready to grab the founders price and join this community, the link is going to be down below. Like I mentioned, I will also have a free YouTube video that I will post later on that explains these concepts. AI Era is for people who want to save time and have the implementation done, ready to go. So, just make sure you join before July 25th so you can get that founders price. So, here's what we can take away from today's video is not to have instructions and external documentation or files that teach Claude how to build your app itself. The architecture itself should be self-explanatory. If I can't look at your app and automatically tell you exactly how it works, what is the flow and how I would build the next feature? AI most probably can't. That's how you need to think. and enforcing all of these through some sort of llinter validation whatever you may choose for your tech stack deliberately throw errors so that your codebase physically can't be pushed to production. So I hope you take these concepts from this video and you start experimenting today. And if you want the complete implementation my exact system then definitely do check out AI era. And when you join, I'll see you on the other