Claude Code lets you build anything you want. Luckily, Y Combinator, the company that helped start Airbnb, Stripe, and DoorDash is very public about what projects you should and what projects you should not start in the age of AI. So after analyzing what their CEO, Gary Tan, has said, I've uncovered three rules you need to follow whether you're working on a side project for yourself or a business you want to grow. The first two rules cover what to build so you save time and money, and the last rule covers how to build it so you're successful. By the way, I'm Austin. I was a COO of a tech startup worth over $25,000,000.
And about a month ago, I used the three rules that I'm gonna cover here to help a nontechnical person use Claude code to build an app that makes over 400,000
a year. So I know with certainty that these rules actually work. Rule number one is avoid the idea trap. Before we talk about what to build, you have to understand what not to build. Because unfortunately, most projects are dead on arrival because people just build the wrong thing. And there are two distinct ways that most people fall into this. The first way is that the user isn't clear. Simply put, you need to have a deep understanding of who is actually going to use what you're building. So there are typically two paths. Path one is you're the only user. Let's say it's an internal tool, an automation that saves you three hours a week, a side project where you're just learning. In this case, you don't have to worry about distribution or getting people to use it because it's only for you. And as a result, you shouldn't worry about making it pretty and you shouldn't worry about scale. You are the only user. You should optimize for speed and function. You need to build it ugly and fast and stop making it look pretty because that's just a waste of time. And path two on the other hand is you want other people to use it. And in this case, distribution or getting people to use it is the only thing that matters. To solve this challenge, you have to understand
who you're building for and what problems they actually have. Here's Gary, the CEO of Y Combinator, talking about the importance of tightly scoping whatever you're building. One thing that we're seeing is that if you, like, scope what you're doing and make the thing that is perfect for that set of people,
there you can't just take ChatGPT and have it do this type of work yet. He's essentially saying, you need to know exactly what problems you're solving and solve those problems in an elegant way. The second way people fall into the idea trap is they jump in front of a steamroller. Let me walk you through a simple example of what this means. Let's say you wanted to build a cyber security tool to help audit a code base. This is a great idea. Right? It could work just for you or it could work for thousands of others. It's really valuable. This is exactly what Anthropic,
OpenAI, and all of the Frontier Labs are working on. You're directly in line competing against the biggest and smartest people on the planet. A battle that you will lose. You're essentially picking up a penny in front of a steamroller that's rolling towards you. So if me and you are David, how do we compete against the Goliaths? Well, the truth is you don't. You need to ask yourself, how can I build something that as AI models get better,
this becomes more valuable, not less? But to help you avoid the idea trap and keep you from building the wrong thing, ask yourself these questions. Is this just for me? If not, can I name five specific people who'd use this today? Two, is this adjacent to AI progress? Will it become more valuable, not less over time? That's rule number one, so you know what not to build. But what should you build? Rule number two is build where you live. We've discussed the importance of knowing who you're building for, but what should you actually focus on? The obvious answer is you should focus on where you have expertise
or the most domain knowledge. And this is correct, don't get me wrong, but not for the reason you think. In today's world, just knowing how to build a website or how to make a Facebook ad isn't valuable. And why isn't it valuable? Because you can prompt AI to get any of that. That's just surface level understanding. But what is valuable is the evaluation letter. Knowing what makes a website actually convert versus a website that doesn't or knowing what makes a Facebook ad successful versus not. That's where the deep value lives. It's the judgment between good and great. A fancy term for this is evals.
Evals are basically knowing how to tell what's good and bad output from AI. Here's Gary talking about why evals are the real moat, which essentially means the real differentiation.
You know, being able to do evaluations of what
models and what prompts are good. It's like that's actually turning out to be the moat for many startups. Yep. Part of design, I think, is actually the empathy for the user. Like, you sort of have to be like an ethnographer.
He said founders as ethnographers,
which I had to look up because we both know that I didn't know what that meant. And here is the definition. A person who studies and describes the culture of a particular society or a group. That is the juice. So Gary's saying the moat or your unfair advantage isn't the AI itself. The moat is where AI can't replicate. The judgment you've earned from watching things actually work and fail in your domain of expertise. A mental frame that I use for this is I think of the letter t. The top of the t is your surface knowledge. It's broad. It covers a lot of width, but it doesn't have a lot of depth. It's shallow. This is essentially the same as anyone who's just asking AI prompts. The vertical of the t, that is where you've gone deep. That's where you've watched something work, where you've watched it fail, and learned the difference between good and great. That's where you've lived. The vertical is your moat. That's where you build. And this should really excite you because of this number. 49.7%
of all AI tools being built are in one category. Healthcare, 1%. Legal, less than 1%. Education,
less than two percent. Half the market is fighting over the same slice.
The rest is wide open. So an engineer might be a 10 in technical skills, but in your domain, they're a zero. And you might be a one in technical things, but in your domain, you're a 10. And that's the d part. And that's what's really valuable. Now, before we get to rule three, which will provide the playbook for you to build something successfully. If this is your first video of mine, welcome to the channel. If this is your second or more, here is our anti SLOP agreement. The visuals, the testing, the time I put into this video, that's for humans. It's not for AI robots or data scrapers. So all I ask is you subscribe as part of this agreement to help this content reach more people so I can keep making videos like this. Moving to rule number three where everyone is a CEO now. So you know what not to build and what to build. But how do you actually build something successfully in this new world? Most people are still operating with the old mindset. I do the work. I execute. In the AI era, that's the wrong game. The new mindset is I orchestrate, I direct, I review, much like a CEO. This shift is from the execution layer to the leadership layer. In the AI era, you already have a team at your disposal. That's Claude Codes, specialized models, custom skills. They're sitting there waiting. The question isn't whether you have a team because you do. The question is whether you're actually ready to lead them. Here's Gary pointing out what the best leaders can do in the AI world. Really
super young teams that basically are starting out with nothing. And they can go from
really 0 to $10,000,000
a year in revenue, sometimes in the course of less than twelve months. And they can do it with less than 10 people. And this point isn't just about startups. Whether you're at your day job, working on a side project, or building a 100 person company, everyone needs to level up to leadership. I actually saw this firsthand with Nick, a nontechnical founder at BDGE, when we were working on launching a Vibe coded app that was entirely built with Claude Coder. One day he called me and he's like, I'm more productive than my engineering team. I'm building fashion than them. They're way too slow. And this was a nontechnical founder who was outpacing his own full time engineers. And it wasn't because he was outcoding them. He was outleading them. He just directed AI better than they did. And after we worked together for about forty five days, we were able to launch an app worth over 400 k. If you're interested in how that actually happened, I do have that link below. I made a whole YouTube video on it. But with that, what is operating at the leadership leadership layer actually look like day to day? And what do successful leaders do? Well, there are six things you need to follow. The first is onboard AI like a new hire. Don't just open Claude code and start prompting a cold. Write a Claude dot m d file first. Think of this file as your AI's onboarding doc. The better context you give it, the less time you spend correcting it later. It's essentially the same way a manager onboards a new employee. Here's a prompt you can use to help create this. The second move is write a plan before you do any work. Don't just prompt and hope. Have AI interview you first to figure out exactly what you wanna build. What's the core problem this feature is solving? What does success look like? What should this not do? Ten minutes of planning could save you hours and hours of time. Here's a prompt you can try to help get information out of you to make sure whatever you're building is actually what you wanna build so you can move faster. Moon number three is give AI employee level permissions. Much like when you onboard employee, you have to give them permissions to do things. And if you've used Cloud Code, you know how annoying it can be to constantly approve permissions for things that should just have access to. For reversible actions, just let the AI agents flow. For anything that's destructive, make it stop and ask for permission. This is a lot like how you'd give employees permissions to do things without your approval or not do things. You wanna protect the agent from itself, but you also don't wanna have to approve everything it does, which is very annoying. So try this prompt to give your agents proper permissioning while working on your computer. Move number four is build a cabinet of specialized experts. Start thinking about creating your own panel of advisers that specialize in a specific task. One trained on your sales playbook, one on your content, one on your finances. Specialized employees be one generalist every time, much like building a team. Here's a prompt you can try to do exactly this. Now if this does sound complex, I built a tool called buildpartner.ai
that solves this exact problem. You can run a skill called slash b p colon expert advice that will take whatever you're working on and run it through an expert in that field so it gives you specific advice from that expert. I love this tool. I built it because I ran into this issue all the time, so you can check that out. Move number five is review like a manager. Have AI bring you volume and you pick the winner. Don't have it do end to end. Have it do tasks that are middle to middle. You want an idea, have it bring you ideas and you approve them. Here's a prompt you can try to help with this. Move six is remove yourself as the bottleneck using Claude's power user features. These are three things I lean on a ton. Hooks. These fire automatically when something happens. Like, every time you finish a session, Claude will log what works and what doesn't. Scheduled agents. These run on a timer remotely. Let's say you wanna run something daily or weekly, Claude can do whatever you want, whenever you want using this functionality. And then loops. These are things that Claude will run automatically on your computer however often you want. This is how you create a system that works while you sleep. End of the day, the more you're a bottleneck, the less you're leading. Here's a prompt to help integrate these into your system. That's rule number three. Everyone is a CEO now, which means you're a CEO now. Stop waiting for somebody to save you. Stop waiting for permission to do these things. You can just do these things. So you now know these three rules. But before you start any project, you need to be able to complete this four question test. Who exactly is this for? Yourself, your team, your clients, or external users?
Be specific or kill it. Anyone interested in next isn't an answer. Is this in front of an AI steamroller? Don't pick up a penny in the path of AI disruption. Build adjacent to it. Do I understand this in practice, not just on paper? If you can't tell me what you've watched fail in real world, you're not the expert yet. Understand your t shape. And the fourth and maybe the most important, is this congruent with the rest of my work? Are you working on something that complements everything else in your life? Set up things that compound over time. If your idea is a one off that pulls you sideways, maybe it's not worth doing. Now if you like this video, you'll love this video where I break down the exact system that Andrea Carpathi,
the former director of AI at Tesla, uses to 10 x his clawed projects. Once you know what to build and how to build it, this system will optimize your setup. I'll see you over there. Peace.