Dan Leshem

Vibe coding tips & tricks

by

Plan > Prototype > Production > Publish


Hey PH! 👋


After building numerous apps with AI over the past year, I wanted to share some helpful tips I've gathered along the way, to help you vibe code your next idea:


1️⃣ Follow the 4P Method: Plan > Prototype > Production > Publish. This is how I build my apps. This method helps me break down complexity and make faster progress. 


2️⃣ Plan before coding. Start with a solid foundation by using AI to create a PRD and map out your features, design, and data model. If possible, add references to existing applications (e.g. “like Airbnb”) and screenshots.  


3️⃣ Focus on creating a working prototype first. Save backend implementation and authentication for later to avoid unnecessary complexity early on. Once you're comfortable with the UX and design, then move forward with the backend.


4️⃣ Starting fresh > Iterate. If AI didn’t pick up on your prompt, sometimes it’s better to start fresh. For small changes, iteration makes sense. For larger issues, especially during the prototype phase, it's often more efficient to edit your initial prompt and start over.


5️⃣ Provide visual feedback. When iterating, share screenshots of your generated app with the AI. This significantly helps with resolving UI issues.


6️⃣ Name your components and versions. Thanks to @rajiv_ayyangar for this tip. Establish a shared vocabulary with the AI by asking it to enumerate, name, and describe different states of your app. This makes it easier to reference specific elements when requesting changes.


What other hacks are you using in your AI builds? Share them below! 👇


Add a comment

Replies

Best
Código Loco

Can you elaborate further on the 4P method

Dan Leshem

@halilgg sure!

The 4P method is just our way of breaking down app building into manageable chunks:


First we Plan - this is where we figure out what we're actually building. That's the most important part in vibe coding. Nothing fancy, just getting clear on the features and what problem we're solving.

Then comes the Prototype phase - we build the simplest version that works. With AI it's very easy to get multiple versions working, and then continue with the one that works best for us.

Next is Production - this is where we make it solid by adding proper database, integrating with 3rd parties and handling all those "what if" scenarios that come up in real use.

Finally, we Publish - deploying the app and getting it out there for people to actually use!

I've found this approach keeps me from getting overwhelmed or lost in the details too early.

Luke

Great point about providing visual feedback! I haven’t tried it myself yet, but how do you typically share screenshots with AI? Do you use it during specific phases of the design process, or is it something you do consistently as you iterate? Also, how do you ensure that the feedback you get is actually improving the UI rather than just creating more complexity?

Dan Leshem

@luke_arwayda normally I just take a screenshot if I need to reference a specific component/layout issue

Derrick Bradley

@luke_arwayda  @dan_leshem I do the screenshot thing and it works great.

Derrick Bradley

Great shout on versioning from @rajiv_ayyangar. I have had quite a bit of success in the planning stage by asking the LLM to ask clarifying questions for each step of my plan and only once it thinks it has the spec right return a known phrase set by myself. Kind of goes against the start fresh > iterate thing but it's helped a bunch.

Kaido Koort

@rajiv_ayyangar  @derrickbradley Good point - helps to prevent an LLM "jumping the gun".


I'm curious about the "Establish a shared vocabulary with the AI by asking it to enumerate, name, and describe different states of your app." - could you bring an example, how to phrase this in practice?

Preben Frenning

Interesting! I have planned going another route - To define the entire DB and flows of each page, in order to not build a whole, lovely app, only to get stuck with auth down the line.

But I will try your approach and rather use dummy content in the beginning, as I find the argument of seeing how far you get with the initial build to be very solid.