This article is part of a series on vibe coding for designers. But unlike the other articles, this one isn’t a playbook. It’s a confession.
I want to be honest about something.
The playbooks in this series, the CLAUDE.md files, the PLAN.md approach, the layers of foundations and protection. I didn’t start with any of that. I learned all of it by doing it wrong first.
CardioVibe, my first app, a blood pressure and heart health tracker, taught me more through its mistakes than through its successes. And if I’d known what I know now before I started, I would have shipped it in half the time with half the frustration.
This article is everything I wish someone had told me before I started.
Mistake 1: I started with the wrong tool
When I first started vibe coding, I didn’t start with Claude or Cursor. I started with Bolt.new.
Bolt.new is a great entry point. It’s fast, visual, and you can go from idea to something on screen in minutes. For a few weeks I was making progress and feeling good about it.
Then I hit a wall.
I wanted to deploy CardioVibe as a mobile app, on the App Store and Google Play. At the time, Bolt.new wasn’t built for that. It was a web-first tool and getting to native mobile was more friction than it was worth.
So I went to a Bolt hackathon, curious to learn more, and what I actually came away with was the realisation that I needed different tools entirely. I switched to Cursor for building and iterating, and Claude for planning and architecture. That combination gave me control I didn’t have before.
Today I wouldn’t go back to Bolt.new for a project like this. For a quick web experiment or a landing page, maybe. For a mobile app you want to ship to real users, Cursor and Claude is the combination that works.
The lesson: Choose your tools based on where you want to end up, not just how easy it is to start.
Mistake 2: I didn’t set up my foundations first
For the first few weeks of building CardioVibe, I had no CLAUDE.md file. No PLAN.md. No persistent context of any kind.
Every session, I’d open a new chat and essentially re-explain the project from scratch. What I was building, what decisions I’d already made, what the design should look like. Claude would get up to speed, we’d make progress, and then the next day I’d do it all again.
The cost wasn’t obvious at first. Each session felt productive. But I was losing continuity between sessions, and without continuity, Claude kept making decisions that contradicted decisions from previous sessions. The codebase started to feel inconsistent. Features that should have felt like they belonged to the same app started to feel like they’d been built by different people.
The fix, when I finally implemented it, was almost embarrassingly simple. A CLAUDE.md file that explained the project, the tech stack, the design principles, and the hard rules. A PLAN.md that tracked where I was and what came next. Two text files that took an afternoon to set up and saved me weeks of confusion going forward.
The lesson: The foundations feel like overhead until the day you realise you’ve been rebuilding the same things over and over without them.
Mistake 3: I let sessions run too long
This one took me the longest to learn.
Claude Code has a context window, a limit to how much it can hold in memory at once. When a session gets very long, Claude starts to lose track of earlier decisions. It contradicts itself. It forgets constraints you set at the start. It starts producing code that conflicts with code it wrote an hour ago.
I would start a session with a clear goal, get into a good flow, and keep going. Hours later, I’d notice things getting inconsistent. Errors appearing that didn’t make sense. Claude suggesting approaches it had already tried and abandoned earlier in the same conversation.
The solution is counterintuitive. Stop more often. Use /clear to reset the chat history between distinct tasks. Claude still has access to all your files, so it doesn’t lose your project context. It just loses the noise of the previous conversation. A fresh session with a clear task and good context files produces better results than a marathon session that’s lost its way.
The lesson: Shorter, focused sessions with clear context files consistently outperform long sessions where everything is in the chat.
Mistake 4: I built too much before testing anything
Designers are planners. We like to think through the whole experience before we start building. We want to see how the pieces fit together before we commit to any of them.
This instinct, which is genuinely valuable in a design process, becomes a liability when you’re vibe coding.
With CardioVibe, I spent weeks building features before I properly tested a single one. I had a vision for the full app: tracking, recipes, exercise plans, breathing coach. I wanted to build towards that vision from the start.
The problem is that when you build a lot before testing anything, you don’t know which parts work until you’ve already built everything around them. When something doesn’t work, and things always don’t work at first, the fix is much harder because it’s tangled up with everything else.
The approach that actually works is almost the opposite. Build one feature. Make it work properly. Test it. Then build the next one. Each feature becomes a stable foundation for the next. Problems are small and contained rather than large and interconnected.
It feels slower. It’s actually faster.
The lesson: One working feature is worth more than five half-built ones.
The tool journey nobody talks about
I want to spend a moment on the tool question because I’ve had a lot of conversations with designers who are confused about which tool to use and feel like they’re already behind because they started with the wrong one.
Here’s the honest version of my tool journey.
I started with Bolt.new because it was the most accessible entry point. It got me moving and taught me the basic shape of how vibe coding works. But it hit its limits quickly for what I was trying to build.
I moved to Cursor because it gave me more control over the codebase and handled the complexity of a mobile app much better. Cursor is where I do most of my iterating: writing new features, fixing bugs, making adjustments.
I use Claude separately for planning and architecture. When I’m starting something new, or when I’m facing a complex decision about how something should be built, I work through it in Claude first. Claude is better at thinking through problems. Cursor is better at executing solutions.
The combination of Claude for thinking and Cursor for building is the workflow I’d recommend to any designer starting today. You don’t need both from day one. Start with whichever feels more approachable; that’s where you’ll likely end up.
The lesson: Your tool stack will evolve. Starting with the wrong tool isn’t a mistake; staying with it when it’s holding you back is.
What I’d tell myself before I started
There are three things I wish I’d known on day one.
Set up your foundations before you build anything. CLAUDE.md and PLAN.md are not optional extras. They are the infrastructure that keeps your project coherent over weeks and months of building. One afternoon of setup saves weeks of confusion.
Test one thing before you build the next. The instinct to build towards the full vision is strong and it will slow you down every time. Resist it. One working feature, properly tested, is the right unit of progress.
Your sessions should be shorter than you think. When in doubt, clear the context and start fresh with a focused goal. Claude works better with a clean start and good context files than with a long conversation that’s lost its way.
None of these lessons are complicated. But none of them are obvious either, until you’ve spent enough time doing it the wrong way.
The thing that doesn’t change
Here’s what I’ve learned across everything: the tools, the mistakes, the gradual improvement.
The quality of what you build with AI is a direct reflection of how clearly you can think about what you’re trying to build.
That’s a design skill. The ability to define a problem clearly, to understand what good looks like, to make decisions about tradeoffs, to know when something isn’t working and why. None of that has changed. If anything, it matters more now than it did before.
The mistake most people make is thinking vibe coding is primarily a technical skill. It isn’t. It’s a thinking skill. And designers, who spend their careers learning to think clearly about problems, are better positioned for this than almost anyone.
You just have to be willing to start messy and learn as you go.
More in this series
Part 1: Solo builder or org builder The two contexts and which skills matter in each.
Part 2: The solo builder playbook Setup, files, and workflow in detail.
Part 3: The org builder playbook Shipping with AI inside a product team.