This is article 2 in a four-part series on vibe coding for designers. If you haven’t read article 1 yet, start there. It explains the two different contexts you might be building in and why they require different approaches.
I built my first app because I couldn’t find what I needed
I have high blood pressure. I was looking for something that combined tracking with practical guidance, food, exercise, breathwork, all in one place. Nothing out there did it the way I wanted. So I built it myself.
I had no engineering background. I had never shipped an app before. I had a full-time job leading a design team of eight people.
Within weeks, CardioVibe was live on both the App Store and Google Play. In the first month, it reached over 100 users, not from ads or marketing spend, but from sharing my story on LinkedIn. One honest post about why I built it was enough.
That experience gave me the confidence to build a second app. NetPay, a real-time pay calculator for UK hourly workers, reached 30 users in its first week from word of mouth alone, with zero marketing.
That experience taught me everything in this article.
Before you start, understand what you’re actually doing
Vibe coding is not the same as coding. When you vibe code, you are directing an AI to write code on your behalf. You are the product thinker, the designer, the decision maker. Claude is the engineer.
This distinction matters because it changes what you need to bring to the process. You don’t need to understand every line of code Claude writes. You do need to understand what you’re building, why, and what good looks like.
Your design skills, your user empathy, your ability to define a problem clearly. These are not less valuable when you’re vibe coding. They’re more valuable. Because the quality of what Claude produces is directly proportional to the quality of the context you give it.
The learning: You are not learning to code. You are learning to direct.
Layer 1: set up Claude to know your project
The single biggest mistake solo builders make is starting a new chat every time they open Claude. Without persistent context, Claude has no memory of what you’re building, what decisions you’ve made, or what problems you’ve already solved. Every session starts from scratch.
The fix is three files that live in your project folder and give Claude a foundation to work from.
CLAUDE.md: your project’s rules and personality
Think of CLAUDE.md as the briefing document you’d give a new employee on their first day. It tells Claude what your project is, what it should always do, and what it should never do.
A good CLAUDE.md includes your project description, your tech stack, your design principles, and a list of hard rules. Things like “never touch the production database” or “always use TypeScript” or “mobile first, always.”
The more specific you are, the better. Claude reads this file at the start of every session, so it’s your most powerful tool for keeping the project consistent over time.
PLAN.md: your master plan
Long chat sessions are the enemy of good vibe coding. When a conversation gets too long, Claude starts to lose context and make mistakes. PLAN.md solves this.
At the start of your project, ask Claude to help you create a plan file. Document your architecture decisions, your feature priorities, your current status, and your next steps. Then, at the start of every new session, reference the plan before you start working.
Instead of explaining your entire project every time, you just say: “Read PLAN.md and let’s continue from where we left off.”
This one habit will save you hours.
Skills.sh: reusable instructions for specific tasks
Skills are sets of instructions you can inject into Claude for particular tasks. Think of them as specialist employees you can call on when you need them.
You might have a copywriting skill that tells Claude to write in your brand voice. A QA skill that tells Claude to test features in a specific way. A design system skill that tells Claude the rules for your components.
You don’t need to build these on day one. Start without them and add them as you notice patterns. As you find yourself repeating the same instructions over and over, that’s your signal to create a skill.
The learning: Give Claude a foundation before you start building, not after things start breaking.
Layer 2: protect your work
This is the layer most solo builders skip. Don’t.
Two databases: development and production
Before you build a single feature, set up two separate databases. One for development, where Claude does all its work. One for production, where your real users’ data lives.
This rule sounds obvious until the day Claude makes a mistake in your production database and you lose real user data. It happened to people I know. It will not happen to you if you set this up first.
Tell Claude clearly in your CLAUDE.md: “Always use the development database. Never touch production unless I explicitly tell you to.”
Your JSON style file: where your design system lives
One of the most powerful things you can do as a designer working with Claude is to create a single JSON file that contains all your design tokens. Your colours, typography, spacing, border radius, everything.
Feed this file to Claude alongside your prompts and it will produce UI that is consistent with your design system every time. Without it, Claude makes its own decisions about these things, and they will not match your vision.
On a separate chat, feed Claude with screenshots of your desired visual style and ask it to create a JSON token file from them. It’s remarkably good at this. Then reference that file in every build session.
Visual references: feed Claude what you see in your head
Claude is more visual than most people realise. When you share screenshots, mood boards, or examples of existing UI alongside your prompts, the quality of what it produces improves dramatically.
Don’t just describe what you want. Show it.
The learning: Five minutes of setup at the start saves five hours of fixing later.
Layer 3: how to actually build
Once your foundations are in place, here is the workflow that gets things built.
Always start in Plan Mode
Before Claude executes anything significant, switch to Plan Mode and ask it to plan first. Read the plan. Ask questions. Push back on anything that doesn’t make sense. Then approve.
This one habit prevents the majority of mistakes. Claude moving fast in the wrong direction is worse than Claude moving slowly in the right one.
Build in the right order
Start with context. Give Claude your CLAUDE.md, your PLAN.md, your JSON style file, and any visual references relevant to what you’re building.
Then ask Claude to build your first feature. Not your whole app. One feature. Test it. See how it looks. Iterate.
Once you have a working feature, ask Claude to help you build your design system from what it’s produced. This creates a feedback loop where the system improves as you build.
Then connect your integrations and APIs before you start iterating at speed. Getting these foundations right early means you’re not rebuilding later.
Use sub-agents for complex tasks
When a task gets complex, don’t try to do everything in one long chat. Break it into smaller, focused agents. One for the UI. One for the backend logic. One for copy. Each one focused on a specific thing produces better results than one chat trying to do everything.
Connect Claude to your tools with MCP
MCP servers are connections between Claude and other tools. If you use Notion for planning, Figma for design, or GitHub for version control, you can connect Claude directly to these tools so it can read from and write to them.
This is where vibe coding gets genuinely powerful. Claude stops being a coding tool and starts being an agent that works across your entire workflow.
Use /clear between tasks
When you finish one task and start another, type /clear to reset the chat history. Claude still has access to all your files, so it doesn’t lose your project context. But it clears out the noise from the previous conversation, which keeps it focused and reduces mistakes.
When something breaks, don’t panic
Claude will make mistakes. Features will break. Errors will appear. This is normal.
When it happens, copy the error message and paste it back into Claude. Ask it to explain what went wrong and fix it. Claude is remarkably good at debugging its own work when you give it the right information.
If you’re ever confused by what Claude is suggesting, ask it to explain it as if you were ten years old. You will get a clear, simple explanation every time.
The learning: The workflow matters as much as the prompts.
What I’d tell myself on day one
Start messy. Your first app will not be perfect. Your first prompts will be wrong. Claude will make mistakes. You will make mistakes. This is the process, not a sign that something has gone wrong.
Protect the foundations. CLAUDE.md and PLAN.md are not optional extras. They are the difference between a project that stays coherent and one that falls apart after ten sessions.
You are still the designer. Claude generates. You decide. Your taste, your judgment, your understanding of the user. That is what makes the difference between something that works and something that’s just functional. Don’t outsource that.
What’s next
Article 3: The org builder playbook covers how AI is changing the way product and design teams work inside organisations, and the practical workflow that makes it work without breaking everything your engineers have built.
Article 4: What I’d do differently is the confession behind these playbooks: the mistakes I made on CardioVibe before CLAUDE.md, short sessions, and one-feature-at-a-time testing clicked.