How I Built a Working Prototype in Less Time Than It Takes to Perfect a Figma File
You know that feeling when you spend two hours perfecting the corner radius on a button in Figma, only to realize nobody’s going to care because the whole interaction is wrong? Yeah. That was me for most of my career.
But recently, I tried something different. Instead of polishing static screens for our next big feature—an enterprise transaction tool that I can’t name but definitely exists—I used Bolt.new (affiliate link—I get credits when you sign up) to build a working React prototype. Not a clickable Figma file. Not a Marvel prototype with awkward hotspots. An actual app that users could poke, prod, and break.
And here’s the thing: it took less time than our usual Figma routine, and the feedback was better. Way better.
Why I Did This (And Why You Might Want To)
Figma prototypes are great. But they’re also… not great. Users click around, nod politely, and then you ship the feature only to discover they never understood how the thing actually worked. The interactions felt fake because they were fake.
I wanted to test something complex—multiple pages, real data flows, interactions that felt like the actual product. So I skipped the usual process and went straight to code. Well, sort of. I let Bolt.new do most of the heavy lifting.
The result? We put together a working prototype in less than three weeks. We tested it in the same timeframe. And users didn’t just tolerate it—they preferred it. One person said, “Wait, this isn’t real?” That’s the reaction you want.
What Bolt.new Actually Let Us Do
Here’s what made this approach worth it:
Users interacted with something that felt real. No awkward “imagine this dropdown works” moments. The dropdown worked. Buttons did things. Pages connected. It wasn’t perfect, but it was credible.
We built interactions fast. Adding a new page or tweaking a flow didn’t require re-linking a dozen Figma frames. We just… built it. The AI handled most of the React boilerplate, and I shaped the details.
We plugged in mock data from an external database. This was huge. Instead of static placeholder text, users saw realistic data that changed based on what they did. It made the whole experience feel less like a prototype and more like an app.
The UI matched our actual product. We brought in design tokens, replicated our existing components, and even integrated an open-source data grid. The prototype looked and felt like the real thing.
The One Big Downside
Because Bolt.new outputs an actual React app, we couldn’t use Maze or similar tools to track interactions. That meant no heatmaps, no automatic click tracking, no quantitative data on where users got stuck.
We didn’t have time to build custom analytics, so we ran moderated usability tests instead. Which, honestly, worked fine. You lose some scale, but you gain depth. Watching someone struggle in real time beats a heatmap any day.
What I Learned (The Hard Way)
Getting from design to prototype is fast. Getting the functionality right takes longer than you think.
It’s easy to generate a UI that looks like your design. Bolt.new is good at that. But if you need specific interactions—like a multi-step form that validates data on the fly—you’ll need to budget more time. Some things are harder to prompt into existence than you’d expect.
Ideate outside the AI, then skip Figma altogether.
This is the part that surprised me. I used to think the flow was: wireframes → Figma → prototype → code. But now I’m thinking: wireframes → Bolt.new. Done.
If you know roughly what you want, you can jump straight to a working prototype. No need to pixel-perfect everything in Figma first. Wireframes to code is faster than wireframes to Figma to prototype. And the feedback is better because users are interacting with real UI.
You don’t need to be a developer, but things can go sideways fast.
I used to work as a front-end developer, so I’m comfortable tweaking React components and debugging. But here’s what actually happened: when things broke, they broke hard.
Bolt.new would sometimes get stuck in a loop, trying to fix something and making it worse with each attempt. I’d go back and forth with the AI, asking it to fix a bug, only to watch it create three new ones. At certain points, the code felt almost unfixable through prompting alone.
My workaround? I’d either fiddle with the code directly or copy the broken part into a different AI tool and try to patch it there. For a designer without coding experience, this could be a dead end.
The saving grace: Bolt.new saves your previous versions. So even when I got stuck, I didn’t lose my work. I could roll back to a version that worked and try a different approach. That safety net mattered more than I expected.
All this back-and-forth consumed tokens. A lot of them. At one point, I was watching my usage climb while the deadline got closer, and I won’t lie—I was stressed. But everything worked out in the end. Just budget for more tokens than you think you’ll need, especially if you’re learning as you go.
The Outcome
We tested a complex feature in less than three weeks, from concept to prototype to user feedback. The users loved it. They engaged with the prototype like it was the real product. And we got feedback that was specific, actionable, and grounded in actual behavior—not hypothetical “I think I would click here” guesswork.
One user even asked when the feature was shipping. That’s when you know the prototype worked.
Should You Try This?
If you’re working on something complex—multi-step flows, data-heavy interfaces, interactions that are hard to fake in Figma—this approach is worth considering. It’s faster than you think, and the feedback quality is better.
But don’t use this for everything. If you’re testing visual design or exploring multiple directions, Figma is still faster. This approach shines when you need to test how something works, not just how it looks.
Also, plan for a learning curve. The first prototype will take longer. You’ll hit weird bugs. You’ll wonder why the AI keeps adding a purple gradient to your buttons. But once you get the hang of it, you’ll wonder why you ever spent three hours perfecting a Figma prototype that nobody clicked through anyway.
So here’s my advice: try it once. Pick a small feature. Skip Figma. Build a working prototype. See what happens.
Worst case, you waste a few hours. Best case, you never go back to static prototypes again.