"The demo is in 5 hours": How panic taught us a better way to prototype with v0

“We just scheduled a demo with a potential user. They want to see the new sales dashboard for feedback. Can you have something ready by 2PM?”

That Slack message from my founders hit me like a bucket of cold water. I looked at my screen: one barely-functional dashboard card, a messy Excel mockup full of sample data, and about 10 browser tabs of half-finished research. The dashboard redesign we'd been planning was supposed to take days, not hours.

The normal playbook was out the window. Usually, we'd spend days going back and forth:

• Mock up designs in Figma
• Get feedback
• Revise the designs
• Realize something doesn't work
• Back to Figma
• Repeat

But five hours? That's barely enough time to boot up Figma and pick a color palette.

We had started this dashboard redesign the right way. First, we created a low-fidelity mockup in Excel to figure out what data and filters we needed. Then, I began building one card in v0, our new prototyping tool (or at least we're treating it that way), just to test the filtering interaction.

v0 by Vercel

Chat with v0. Generate UI with simple text prompts. Copy, paste, ship.

Now that single card and our ugly spreadsheet were all that stood between us and an important user demo.

My first instinct was to tell my founders we'd have to show the Excel mockup. But my CTO pushed back hard: "We can't show them a spreadsheet. They need to feel what it's like to use this thing."

He was right. Our dashboard's value was all in the interactions—how filters would cascade, how data would update in real-time, how everything would flow together. A static spreadsheet would kill any chance of meaningful feedback.

That's when it hit me: I was thinking about this all wrong. We didn't need a perfect design - we needed something people could actually use and play with. I already had one working card in v0. Not a mockup, not a prototype, but a real, interactive component. What if we completely flipped our usual process? Instead of designing the perfect layout first, what if we just... built the rest of it on v0?

It seemed backwards, maybe even a little reckless. I hadn’t heard of someone testing it out before with users. But we were out of options.

V0 let me:

1. Build real, working components without touching our codebase
2. Use actual data instead of numbers that didn’t make sense together
3. Create working filters and interactions immediately
4. Share a live, interactive prototype through a simple URL

I dove in. The next four hours were a blur of:

• Copying the base card's structure into new cards
• Adapting it for different data we wanted to showcase
• Adding filter logic (by people and date ranges)
• Testing interactions
• Fixing bugs on the fly

No Figma. No back-and-forth between design and code. Just plain English. After 24 rapid iterations, I had something that wasn't just a prototype—it was a working proof-of-concept that users could actually test.

The demo arrived. If we'd shown the Excel version, I can imagine how it would have gone: "So, imagine these numbers automatically update when you filter..." *awkward scrolling through sheets.* "And pretend you could click here to drill down...". We'd have spent the whole time explaining what could be instead of learning what should be.

Instead, we jumped straight into real usage. The user filtered data, watched updates happen in real-time, and explored the dashboard exactly as it would work in production. No imagination required.

The feedback was immediate and precise, focused entirely on value instead of implementation:

• "The numbers here are OK but what would really help me is if I can see rates and values"
• "What happens if I group by week instead of month?" and "Can I compare different time intervals?"
• "Could I drill into what the at-risk deals are here?" *clicks* then “OOOH!”

No hypotheticals. No "well, in the real version..." disclaimers. Just concrete feedback about actual functionality.

We would have never gotten this quality of feedback from static mockups. More importantly, we wouldn't have gotten it at all if we'd stuck to the traditional design approach—we'd still be wrestling with auto-layout inside tables.

What we learned

This accidental experiment taught us something crucial: the traditional "design → prototype → code" workflow exists mainly because of tool limitations, not because it's the best way to work.

Here's what made the v0 approach different:

1. Real data drove design decisions - Instead of mocking up charts with random numbers that didn't make sense together, we could immediately see if our metrics and calculations worked. Those "rates and values" the user asked for? We added them in seconds, not days, with real mathematical relationships intact.
2. Interaction = truth - That "OOOH!" moment when the user drilled into at-risk deals? You can't get that from a Figma prototype that easily.
3. Speed through focus - Instead of stringing frames together in Figma to create interactions and then checking them in prototype mode, you can directly build and test interactions in real-time. It’s just pure user-centric problem-solving.
4. Faster path to insights - By putting working software in front of users immediately, we got actionable feedback in hours instead of days or weeks. Each iteration taught us something concrete about user needs, without the “open-to-interpretation” layer of static designs.

When to use this approach

This workflow shines when:

1. Your feature is interaction-heavy (like dashboards, multi-step forms with branching logic, or data exploration interfaces)
2. The value is in how data connects and transforms an interface
3. You need feedback on the actual experience, not just the look
4. You're working against time like we did

Don’t use this approach if your prototype is multi-page; I don’t think v0 supports this at the moment. Also, be mindful of the fact that generations can take time and slow you down. Instead, break up the components and then bring it together at the end.

Try it yourself (in 1 hour)

While my story was about a 5-hour dashboard sprint, you can test this approach in just one hour. Here's how:

1. Pick one interaction to improve (10 mins)
   • Choose something small but annoying in your current product
   • Maybe it's a form that could be smarter, or a feature that needs better validation
   • Don't overthink it—pick the first thing that bugs you
2. Build one working piece (30 mins)
   • Skip the Figma file
   • Create just the core interaction in v0 (it’s free)
   • Proxy the data from your product to make it real (if you can)
3. Share & learn (20 mins)
   • Send the URL to a colleague
   • Watch them try to use it
   • Note what confuses them
   • Rinse and repeat

The goal isn't to finish the feature. It's to prove (or disprove) your idea with working code faster than you could with mockups.

I'm not saying never use Figma. It's been my trusty prototyping side-kick for years. But for data-heavy or interactive features? Try building it on v0 directly. You will be surprised how much faster you can move and how unshackled you will feel.

Notable mention: Check out Chris Tate's v0 portfolio. It's amazing what this tool can do!