Vibe-coding prototypes
I ship working React prototypes built end-to-end in Claude Code — clickable artifacts PMs, engineers and users can pressure-test, not deck screens.
01 - Why in code
Things change so fast these days, we can no longer afford spending days (or even sometimes weeks) in Figma to visualize ideas we need to present to stakeholders and test with users. With Claude Code I just build a small React app or sometimes super basic HTML page to bring it with me to meetings with the leadership, and show the idea basically right after it appeared in our minds.
02 - Process (very simple)
Rules
Before I even began building my first prototype I set up a global CLAUDE.md file — basically a set of rules for Claude to know each time a session begins. Did it once — good to go!
- Who am I — product designer
- How I plan to use it — mostly prototyping
- What tech stack to use
- What not to do — e.g. don’t write tests, it’s not needed for my tasks and only eats tokens
Brainstorm
We have a structured back-and-forth to name the problem, the persona, the hypotheses and the shape of the concept before we start building. I use Claude’s superpowers plugin where it invokes brainstorming skill to do so. I personally love this skill, sometimes it asks such great questions that it makes me go “Huh, interesting!”.
Plan and execute
I delegate this part to my pal Claude to plan its work how it thinks would be more efficient. I like that in this superpowers plugin it creates plan and executes what we have agreed on.
03 - Tech side of things
How I collaborate, iterate and publish
A working prototype is only useful if the right people can reach it. Every prototype I build lives in an Azure DevOps repository and moves through the same git-driven loop the engineering teams use.
Branch per concept
Different candidate paths or version get their own branch. It’s also super useful in collaborative work with PMs, other designers and UX writers. Each of us can branch from the main version, implement changes and create pull request to merge their changes to main source.
Commit as decision log
Each commit contains a small design decision. Reading back through the history is reading back through the design reasoning. And it’s a version control which can’t be overrated.
Deploy pipeline
This is purely technical process established by our engineers for designers and PMs so we could publish our prototypes to have a link to share with either stakeholders or users. Azure pipelines build the prototype and push it to an App Service URL. All we need is to set up a repository in the very beginning of our work to later push our code to be deployed.
The open question for now — handover
For now I still push coded prototypes to Figma via Claude Code to then polish it and prepare for the engineering handoff. Together with engineers we are now looking for a solution to (what if?) eliminate Figma from the process and hand over React app we built.
04 - Why it’s cool
Fast and flexible solution delivery
Apart from the obvious benefit of speeding up visualization of ideas, I want to highlight how much the quality of usability tests has risen. When we created prototypes in Figma and wanted to give users freedom to explore the solution how they would interact with it, our hands were to some degree tied when it comes to filling the prototype with data, make this data flow across all screens, apply changes fast and so on. When we now bring a React app to the users they can do so much more, and the system state is preserved, the data points are considered, the prototype behaves almost like the real platform in users’ eyes. This gives us more insights from testing sessions because users are more relaxed, they need to think less and adapt less than it was with Figma prototypes. I can’t even count how many times I used to say “sorry, this is not clickable, this prototype doesn’t allow that”. Now we can just focus on getting these high quality insights we need so much.
05 - What doesn’t work
Ways of working need to be defined clearer
Coded prototypes are not production ready. At least in our organization today. I observe a great temptation to treat vibe coded prototypes as something we can ship to production or something developers can “polish” and ship to production but it’s not that simple. There is a knowledge gap from product side on what code is and how it should be written. We can’t just vibe code whatever and however we want and then ship it. To do so our agents should follow certain rules, patterns, architecture that platform follows. Security measures should be followed. And all these steps should be defined into a clear ways of working we can all follow and ship consistent product.
Want to see a prototype in action?
I’m always up for a conversation about vibe-coding, Claude Code, or how a working prototype could fit into your own process. Let’s talk.
Next
Creating Claude Code skills