How Vibe Coding has Impacted My Discovery Process

Best practices to build with tools like Replit, Lovable, and V0. Using prototype tests to investigate the problem space.

Welcome to week 2 of building my bootstrapped b2b business.

Need to catch up on what I did before?

• Building a Bootstrapped B2B Product with Gen AI (0 to 1): Background, process, and principles

• Week 1: Hunting for My Underserved Niche ICP: Criteria for my niche, collecting signals on an underserved niche
  
  

Last week I sent out roughly 150 LinkedIn requests for discovery interviews as part of my ICP smoke test. I decided to show several prototypes to each interviewee after a 15-minute exploratory interview section.

I got to vibe coding way earlier in my discovery process than I had anticipated.

This article dives into:

• Why I used prototype tests much earlier in my discovery process than before (prototype testing to understand the problem space)

• Best practices and pitfalls when building with Replit

Prototype testing to understand the problem-space

I’ve always been an advocate for ‘layering’ tests.

• Start at your riskiest assumption (high importance, no evidence)

• Start with the cheapest, most lightweight test at first, and increase complexity/cost as uncertainty is reduced.

Creating a high-fidelity prototype used to require a designer or frontend engineer. Solution-ideas only made it to the prototype-test stage after having passed several cheaper tests. I usually only tested with one prototype at the time, gauging the usability of a solution-idea we were pretty much convinced of.

But now, prototypes are cheaper and faster than ever to make.

With tools like like Replit, v0 and Lovable, I can single handedly spin up three high-fi prototypes in an afternoon.

That means I can run prototype tests to explore:

• Multiple solution ideas for the same pain

• Or, multiple pains entirely - is the underlying customer opportunity really there?
  
  

Example:

• Prototype A → Idea 1 for Pain 1

• Prototype B → Idea 2 for Pain 1

• Prototype C → Idea 3 for Pain 2

  
  This helps me figure out not just what works, but what's worth working on.
  
  

  

  Interviews vs. Prototypes: It’s Not Binary

  I recommend stacking discovery methods, and strongly advocate for using both exploratory interviews and prototype tests.
  

  Interviews are traditionally better to help you understand the problem space without bias.

  (Potential) users tell their story freely and (hopefully) bring up the pain they experience without being led by the interviewer.
  

  The issue is that through exploratory interviews, we don’t learn about latent needs.
  

  People can experience significant friction points without noticing them, if they accept them as a ‘hard fact of life’.
  

  Sometimes showing your idea through a prototype gets you an earnestly delighted reaction and a “Yes, this is much better than how I do things today!”, even if no pain point had come to mind.
  

  Showing multiple prototypes for varying ideas to the same tester can help you reduce bias. You’ll see the full range of your tester’s excitement levels.
  

  

  
  Vibe Coding with Replit, v0, Lovable and co.: the fundamentals

  So how do I spin up three prototypes in one afternoon? Here are my best practices:

  The 70% first-shot rule

  With a good initial prompt it’s relatively easy to get to 70% of what you had in mind.

  But things get painful quickly when you start to iterate, and your app starts crashing.
  

  Welcome to the rabbit hole of “Let me just quickly add….”
  

  Getting from 70 to 80% takes time and patience. Getting above 80% without coding skills seems near impossible.

  Barbara Lampl (behavioral mathematician + AI strategist) kindly explained to me why LLMs struggle so much with iteration:
  
  “𝘠𝘰𝘶 𝘤𝘢𝘯’𝘵 𝘪𝘵𝘦𝘳𝘢𝘵𝘦 𝘰𝘯 𝘢 𝘷𝘪𝘣𝘦-𝘤𝘰𝘥𝘦𝘥 𝘱𝘳𝘰𝘵𝘰𝘵𝘺𝘱𝘦. 𝘛𝘩𝘢𝘵’𝘴 𝘯𝘰𝘵 𝘩𝘰𝘸 𝘨𝘦𝘯𝘦𝘳𝘢𝘵𝘪𝘷𝘦 𝘈𝘐 𝘸𝘰𝘳𝘬𝘴. It generates something new every time.”
  
  Her rule of thumb: 𝗔𝗶𝗺 𝗳𝗼𝗿 𝗮𝘁 𝗹𝗲𝗮𝘀𝘁 𝟳𝟬% 𝗼𝗳 𝘄𝗵𝗮𝘁 𝘆𝗼𝘂 𝗵𝗮𝗱 𝗶𝗻 𝗺𝗶𝗻𝗱 𝗼𝗻 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝘁𝗿𝘆. If it’s not 70% there, start over with better input.

  (Find my full conversation with Barbara here)

  
  Getting the initial prompt right
  

  There are three ways to kick off a new vibe coded project (and each way has its diehard evangelists):
  

  1. Full PRD

  This way usually gets the best results for me with Replit - my go-to vibe coding tool.

  At first, I debate with ChatGPT to crystallise my idea. I feed it my high-level idea, my ICP, what I know about the competitive space, and ask it to poke holes, reduce complexity, and tell me what important unmet needs I am missing. When I’m happy with the prototype or MVP outline, I ask chatGPT to write a prompt for Replit. I specify that it’s for Replit, just in case ChatGPT already knows how to write a prompt that Replit likes.
  

  Find an example PRD-style prompt for Replit here, under “Building prototypes with Replit”.
  

  Find the deployed output (a click prototype) here.
  

  2. Loose concept
     

  “I want to build an app to help field service engineers document the services they do for customers.”
  

  3. Feature by feature
     

  Start with a core feature, and slowly build on it feature-by-feature. Use a new chat for each feature. This allows you to tackle small components one at a time. Jumping across too many files at once usually leads to a mess of errors that are hard to untangle.

  Getting the first iteration of your product right still feels a bit like rolling the dice. You can try each of these ways, to see what gives you the best initial result. If you’re hell bent on executing the idea you have in mind, go with 1 or 3.
  
  If you want AI to help break you out of your ‘idea-box’, give 2 a whirl.

  
  Iterating on your first shot: Getting beyond that initial 70%
  

  Can’t tell good code from bad code? Be careful

  Before I dive in with practical tips, some words of warning.
  

  𝘓𝘓𝘔𝘴 𝘴𝘩𝘰𝘶𝘭𝘥 𝘣𝘦 𝘶𝘴𝘦𝘥 𝘵𝘰 𝘴𝘵𝘳𝘦𝘯𝘨𝘵𝘩𝘦𝘯 𝘺𝘰𝘶𝘳 𝘴𝘵𝘳𝘦𝘯𝘨𝘵𝘩𝘴, 𝘯𝘰𝘵 𝘤𝘰𝘷𝘦𝘳 𝘺𝘰𝘶𝘳 𝘸𝘦𝘢𝘬𝘯𝘦𝘴𝘴𝘦𝘴.
  
  You need to be able to judge whether the output is good or bad.

  If you don’t know what good code looks like, you can’t build an app that is safe to release ‘into the wild’. You might be leaking personal data, or your app might break in the middle of a critical, time sensitive workflow for your customer.

  Because I personally can’t code, I’ve only used Replit to build click prototypes.

  If I want to build a shippable product, I will involve a (senior) engineer, who will hopefully be able to build much faster, because:
  

  • They can use my PRD + prototype to understand what I want (and poke holes)

  • They can use tools like Cursor or Windsurf to code faster
    

Click dummy instead of functional MVP

You don’t need a functional MVP for a user lab, a simple click prototype is enough.

I’ll specify in my initial prompt that the goal is to build a clickable frontend, without backend or data storage, showing dummy data.

It’s not surprising that Replit struggles much less with making changes to a clickable frontend - there simply isn’t so much to break.

Functional MVP using only Replit

Want to build something that works? Check out the tips below.

To reiterate the message above: If you can’t understand the code that is written and haven’t had help from a good developer, don’t direct traffic to your MVP.

Vibe coding a functional app

1. Add logging early on. This will help you debug faster later on, and it will allow you to see how users are behaving inside your product. You can build custom loggers or just use print() or logging module to start.

2. Keep prompts focused and specific. Avoid requesting too many changes at once. It can confuse the LLM and lead to poor results.
   

3. Use Replit as a sparring partner, no coding allowed!
   
   Start by asking for solutions without writing any code. Focus on discussing the logic first, and only move forward once it makes sense.
   
   Ask which features are adding technical complexity. See if any can be removed or simplified. Also explore other ways to reduce complexity.
   

4. If a file gets too large, ask the AI to refactor it into smaller, separate files.
   

5. Ask the agent to propose a new approach, in case a piece of new functionality keeps breaking. Sometimes a new angle is all it takes.

6. Start a new chat for each new piece of functionality, or in case you’re stuck in a debugging rabbit hole. Avoid piling all changes into a single session, it makes things harder to track and increases the chance of errors. When you keep iterating in the same chat, the AI accumulates a lot of assumptions based on the conversation history - previous code versions, partial explanations, mistakes, and attempted fixes. Over time, this can clutter the model's "mental model" of your code.
   
   What does starting a new chat do?

   
   - Wipes the memory clean
   - Lets you describe only the current, working state + what you want to change
   - Avoids accidental reliance on broken or outdated code paths.

   
   It’s like bringing in a new engineer with a fresh set of eyes. It can help to ask the ‘old chat’ to summarize the work it’s done to feed that into the new chat. This way, your new engineer has a bit of background.
   

7. Roll back when needed.
   If you're totally stuck, revert back to an earlier state. Replit automatically creates snapshots and has a big “roll back to this point” button in the app. I use this button a lot.
   

   
   Manually Fixing or Rewriting the code with Cursor or Windsurf

   You can use tools like Replit, V0 or Lovable as a first, crude brush stroke, but you can’t refine it to ‘perfection’. To get there, you’ll need to ‘manually’ edit the code. Tools like Cursor or Windsurf can help.

   Option 1:
   

   • Start from scratch in Cursor, using your learnings from your Replit process to get your first prompt right

   • Export your code out of Replit, debug in Cursor, and re-import into Replit
     

   

   
   Final Thoughts: Vibe Coding Unlocks Brand New Capabilities - But Handle With Care

   What used to take a week now takes an afternoon.
   

   Tools like Replit, Lovable, and V0 have changed the game - not just for building, but for learning. I can test multiple ideas earlier, faster, and cheaper. Instead of using a prototype test to test the usability of my #1 idea, I can have testers compare multiple prototypes to a variety of solution ideas, targeting a variety of customer problems. This is a game changer.
   

   Prototype testing is no longer reserved for the end of discovery. It's a wedge I now use to crack open the problem space.
   

   But this speed only helps if you know how to distinguish signal from noise.
   If you're not careful, you’ll vibe code your way into false positives, or worse: shipping an MVP that really should not have seen the light of day.

   
   

   ---

   Special thanks to Barbara Lampl, Dr. Mario Lenz, Simonetta Batteiger, Renato Costa, Thomas Brouwer, and Jerel Velarde for sharing your vibe coding experiences with me.

   ---

   Next article:

   • How I Run a User Lab: A step-by-step breakdown of how I prepare, facilitate, and extract insights from prototype testing in a controlled environment.

   • Customer Discovery 101: My hard-won do’s and don’ts for interviewing (potential) users without leading the witness—or wasting your time.

   • What I Learned: Results from my own user lab and exploratory interviews, as I build my B2B SaaS product from scratch.
     

   I’ll be going on holiday next week, so please forgive a two week hiatus in my journey to building a bootstrapped B2B business :)