R5 at Levelpath
A prototyping environment built to close the gap between having an idea and showing it.
Problem
We were at the start of a major platform replatform. Design velocity was the bottleneck, and Figma was a big part of why.
Designers were spending most of their time building static mockups, not thinking through interactions. The bigger issue was what Figma simply couldn't do: complex conditional flows, realistic data, multi-step user journeys. Prototyping at the fidelity the product actually needed wasn't really possible. So it mostly didn't happen.
PMs had it worse. They had ideas but no way to prototype independently. Every prototype went through a designer, which meant waiting, translating, and often losing nuance in the handoff. The team was moving slower than it needed to.
The challenge wasn't a lack of ideas. It was that the tools we had couldn't keep up with the pace we needed, and the gap between “I want to explore this” and “I have something I can show” was too wide.
Role
It started with a challenge from my manager. Another designer and I were tasked with building a prototype for a customer event entirely in Claude Code, no Figma static screens. Two weeks later we had something working, and it was fast enough that I couldn't stop thinking about what it would look like if we built the right infrastructure around it. That weekend I opened a new repo and started planning R5.
I had a working version by the end of that first weekend. Over the next two months I built on it alongside my regular design responsibilities, refining the system, adding features, and making it reliable enough for the whole team to depend on.
The goal was to make that speed accessible to everyone on the team. Designers, PMs, anyone with an idea should be able to go from concept to working prototype without the usual bottlenecks. The key was giving the AI knowledge of how our product was actually built — the components, the design language, the rules — so that anyone could use it without needing to know any of that themselves.
I knew it would be faster. I didn't expect it to be this good.
Insight
When the team took on the challenge of designing using only Claude, the speed difference was immediate and hard to ignore. Prototypes that would have taken days were happening in hours. That wasn't an incremental improvement. It made the old way feel broken.
But the more important realization came after. When PMs started showing up with rough prototypes that actually matched our design language, it was clear something bigger was happening. The speed hadn't just helped designers move faster. It had made prototyping accessible to people who had never done it before.
Those two things reinforced each other. Speed lowered the barrier enough that more people could participate. More participation validated that the speed was worth investing in. The question stopped being “is AI prototyping faster?” and became “how do we make this reliable enough for a whole team to depend on?”
I was able to create general prototypes — mind you, very ugly — but it helped talk through the ideas with the design team. That way you could use your time and expertise to truly design.
Solution
R5 was built around a simple idea: describe what you want to build, and get a working first draft back. Not a static screen. A real, interactive prototype that already used the right components, the right tokens, the right design language.
You could scaffold something new from scratch, or duplicate a prototype a teammate had already built and extend it. Both paths started the same way: describe the problem, describe the screen, and let the AI take a first pass. The difference from using a general-purpose coding assistant directly was that R5 gave it knowledge of how our specific product was built — the components it could use, the layouts available, the rules it had to follow. It wasn't guessing at a design system. It knew ours.
Forking was one of the features that changed how the team worked together. Because prototypes were fully coded with real interactions, duplicating a teammate's work meant inheriting something genuinely useful, not just a static frame to redraw. You could grab something, extend it, and have a new direction in the time it used to take to open Figma.
Forking was frictionless. See something a teammate built, grab it, extend it, done. What we were sharing were fully coded prototypes with real flows and transitions. That is worth a lot more to copy from.
The other thing R5 made possible was exploring multiple directions fast. Generating five versions of an idea, picking the strongest one, and moving forward. That kind of early exploration had always been too expensive in Figma to do regularly. In R5 it became part of how the team worked.
R5 did not replace design judgment. It removed the tax on using it. The thinking stayed the same. The time it took to act on that thinking got a lot shorter.
Outcome
The clearest measure of R5's impact was time. Prototypes that would have required engineering effort and days of coordination were happening in a single day. In one case, I built multiple variants of a new component using real customer data — something that would have been impossible in Figma and impractical to ask engineering to build just for testing. It was done in a day and went straight into a customer session.
Across the team, output increased by at least 150%. Eight people were using R5 almost daily, and the quality of what they were producing went up alongside the speed. Designers were exploring more directions earlier. PMs were showing up to design reviews with prototypes alongside their design briefs.
One of the quieter wins was a shared sample data system. Before it existed, every prototype used a different data set, which made things feel inconsistent and made it harder to compare work across the team. The updated version had a sample dataset baked in so every prototype pulled from the same source. It sounds like a small thing. It made collaborative prototyping feel coherent for the first time.
We're now shipping real, functional code prototypes in hours instead of days, seeing at least a 150% increase in output. Between the fake datasets and Blob storage integration, there's nothing we can't prototype. Honestly, I'm not sure I'll touch Figma much anymore.
The shift that mattered most was not just that the team moved faster. It was that more people were participating in the prototyping process at all. Design stopped being a bottleneck and became a conversation.
What I'd do differently
R5 worked, but building it fast meant accepting some tradeoffs.
The first was accessibility. There was still a learning curve for new users who weren't comfortable with AI tooling, and lowering that barrier earlier would have gotten more people using it sooner.
The more structural issue was how design system knowledge was stored. It ended up scattered across six different formats: markdown files, JSON, CSS, and logic hardcoded directly into scripts. Adding a new component meant updating three or four places at once. Manageable at the time, but the kind of thing that compounds — every addition slightly more expensive than the last, and every inconsistency slightly harder to find.
If I were solving it again, all of it would live in one place: a single source that everything else generates from, so changing one thing changes everything downstream.