8 Comments
User's avatar
Ravid's avatar

These are great tips on how to be better at prototyping using ANY vibe coding tool, I really don't see the difference from other tools.

The essence is get the data, get the design and UX requirements in advance before starting to vibe code. Use them all wisely.

Expand full comment
Ravi Mehta's avatar

Hi Ravid, totally agree... I've used this same approach with Lovable, v0, Magic Patterns. It really does work across the board. The prep work is what makes the difference, not the specific tool. Once you have your data and design requirements sorted, any of these tools can help you move fast.

Expand full comment
Noe's avatar

Thanks, Ravi. Once the prototype is done and validated, how do you hand this work over to the developers? Do you redesign it in Figma, or do you go with this? And what’s your opinion on using tools like Lovable or Replit to prototype and directly deliver it to the client as a product?

Expand full comment
Ravi Mehta's avatar

Great question! Counterintuitively, I think the right next step after the prototype is to draft a spec that pulls everything together. Specs used to be the start of the product lifecycle because they were the cheapest artifact to create... each follow-on artifact (wireframes, designs, prototypes, MVPs) used to be more expensive, but also provide much more signal.

Today, it's pretty fast to make a prototype, so a good spec often comes in the middle of the process. It pulls together all of the learnings and artifacts into a shared understanding of what needs to get shipped to production. That will include the prototype, user research learnings, design specs, goals, or any other requirements to align the team on the path to launch.

I think you can use something like Lovable to get a prototype in front of the client, but probably not for production code that needs to scale. That still needs to go to engineers who will use an AI tool like Cursor, Claude Code, Codex, or Github Copilot. To me, Replit sits somewhere in the middle... you can use it both for rapid prototyping or for production code for simpler projects.

Expand full comment
Rainbow Roxy's avatar

Wow, the part about capturing the dynamic reality of trip planning really stood out to me; how do you see this approach scalling beyond specific travel features, Ravi, because this is truly insightful!

Expand full comment
Ravi Mehta's avatar

Thanks so much! I'm actually working on another post right now where I build out a music discovery prototype, and I'm finding the same thing... data is just as critical there. We need accurate albums, songs, and album covers to make the experience feel authentic. I think data is often the unsung hero of a really good prototype. Users can smell when something is off... so this approach seems to work really well for any interface where the underlying data matters. Glad this resonated with you!

Expand full comment
Gopal Shenoy's avatar

Ravi - Nice read. I used Bolt 2.0 last month and noticed that supabase is very tightly integrated and it created all the data it needed based on my prompts. Prior to this in Bolt 1.0, the integration was complicated that I was forced to use mockdata like you have described above. Now I can ask it to add more data points into the existing data tables just by prompting.

Expand full comment
Ravi Mehta's avatar

Gopal, thanks for sharing! Agreed... database support has gotten really good across a number of these tools. Lovable Cloud is great and v0 has strong support for Supabase too. That definitely helps build prototypes that are much more useful... being able to persist data is critical to a lot of user testing.

Expand full comment