The first thing to understand about vibe coding is that it means something completely different depending on where you’re building from.
A year ago I started experimenting with Claude Code. I was a Head of Design at a fintech company, leading a team of eight, with years of experience working inside large organisations. I also had an idea for an app I wanted to build, and no engineering background whatsoever.
What happened next taught me something I didn’t expect: the skills that make you effective as a vibe coder inside an organisation are almost the opposite of the skills you need when you’re building alone.
This is the first article in a four-part series on vibe coding for designers. By the end of it, you’ll understand the two fundamentally different contexts you might be building in, and why that distinction matters before you write a single prompt.
The question nobody asks first
Most vibe coding content starts with tools. Which IDE. Which model. Which framework. But before any of that, there’s a more important question:
Who are you building for, and with what constraints?
Because the answer completely changes how you should work with AI.
If you’re building alone, a side project, a startup idea, an app you want to ship, you have total freedom and total responsibility. Speed is your friend. Process is your enemy. You’re the designer, the product manager, the QA team, and the engineer all at once.
If you’re building inside an organisation, as part of a product or design team, with engineers around you, with stakeholders and sign-off processes, you have a completely different set of constraints. Speed still matters, but so does consistency, collaboration, and not breaking things that other people depend on.
The mistake most people make is applying one approach to the wrong context.
The solo builder mindset
When you’re building alone, the most important thing is to start. Not to plan perfectly, not to choose the right stack, not to have a clear design system before you write a line of code.
Start messy. Iterate fast.
This sounds obvious, but it runs counter to everything most designers are trained to do. We’re taught to research before we build, to design before we prototype, to validate before we ship. That discipline is valuable in a team context. In a solo context, it can become paralysis.
The solo builder uses AI differently too. You’re not delegating tasks to Claude, you’re thinking out loud with it. You’re asking it to help you figure out what to build, not just how to build it. You’re using it as a co-founder who happens to know how to code.
The learning here: Treat Claude as a thinking partner, not just a coding tool.
The org builder mindset
When you’re building inside an organisation, the dynamic shifts completely.
You’re not the only person affected by what you build. There are engineers who will maintain your code, designers who will extend your components, product managers who will build on your features. The decisions you make ripple outward in ways they don’t when you’re building alone.
This means that working with AI inside an organisation isn’t just about what you can build, it’s about how you build it in a way that the rest of the team can understand, extend, and trust.
The most forward-thinking engineering teams are already writing guides for non-technical people to ship code with Claude. Not because they’ve lowered the bar, but because they’ve recognised that the bar is changing. The question is no longer “can you code?” but “can you direct AI to produce code that meets our standards?”
The learning here: Inside an org, your job is to direct Claude within the constraints of your team, not to work around them.
What they have in common
Despite the differences, both contexts share the same foundation.
In both cases, Claude is only as good as the context you give it. In both cases, you are still the designer, your taste, your judgment, your understanding of the user is what separates good output from mediocre output. And in both cases, the biggest mistake you can make is treating Claude like a search engine rather than a collaborator.
The tool doesn’t change. The way you work with it does.
What’s coming next
In the articles that follow in this series, I’ll break down each context in detail, and close with what I learned the hard way on my first app.
Article 2: The solo builder playbook covers the exact setup, files, and workflow I used to ship three apps as a designer with no engineering background.
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.
Article 4: What I’d do differently is a confession, not a playbook: the mistakes I made on my first app (CardioVibe) and what I wish someone had told me on day one.
If you’re not sure which one applies to you, read both. Most of us are building in both contexts at the same time.