The Definitive Guide to Getting Your App From Idea to Reality Vibe Coding

Below is my current workflow for vibe coding. I use Roo Code boomerang mode with Gemini 2.5 as the orchestrator and Claude 3.7 as the coder.

Step 1: Create a Project Brief/PRD document

The single most important task when vibe coding is creating a project brief manually (maybe a little LLM help...). The LLM has to know what its building to actually build what you want it to.

Try and be as detailed and as specific as your skill level allows you to be. The more specific and detailed you are, generally, the better the results. As a rule of thumb, you MUST include the name, what it does and a user flow (e.g. user logs on, user creates to do list, user ticks off to do list as he completes his tasks etc.).

I have included my custom instructions for my Claude project where i create all of my project briefs. You can use this template and explain your project briefly to an LLM and it ask it to fill it in.

This document will not be edited by the LLM, and it will serve as a reference to the original vision throughout completion of the project.

Step 2: Create a folder in /documents where your code will live

Step 3: Place the project brief in your root directory

Step 4: determine whether you need to provide documentation to your LLM

The main two weaknesses of current LLMs in the context of vibe coding are: context management (when the agent context window fills and you have to start again or it starts hallucinating), and outdated technology knowledge (when the LLM codes based on an old version of a technology which has been updated since its knowledge cutoff).

The latter is 90% mitigated through boomerang mode (thank you Roo Code team, you're the best!), or using a memory bank which the model periodically updates and reads. A good memory bank is the one provided in the cline docs

The former depends on the model. Claude 3.7s cut off is Nov 2024, whereas Geminis is Jan 2025. If there is anything new or any breaking updates to any technology you are using, you should provide documentation through 1 or these 2 ways:
1. MCP servers: perplexity, fetch, brave etc.: the LLM can search for the specific information needed
2. Creating a document for reference e.g. 'sanity_reference': you insert an overview of all of the docs and guides into one file in your project directory and you tell the LLM to refer to it and request docs as needed. Alternatively, you can tell it to use firecrawl MCP to scrape that specific page from the documentation.

Step 5: Prompt Your LLM

All of the hard yards are done with the project brief. All you need to do is tell the to read it and create a plan for implementing it.

If you have documentation reference files, tell the LLM about them and how to use them.

I also like to tell the LLM to use its MCP server access to do research for whatever reason. Here is what it normally looks like for me:

"You are in an existing next.js 15.2.4 project, which i have created the foundations for. There is a projectBrief.md which was used to create it, but there is a specific file called DESIGNER_HANDOFF_UPDATED.md written directly for you. We had one session previously and created IMPLEMENTATION_CHANGES and ACTIVE_CONTEXT.md. Your knowledge may be out of date for next.js, so you can use perplexty MCP or just ask me for documentation. Please ensure sanity is integrated fully, this website is going to be content heavy. Your knowledge is a bit out of date regarding it, so i have created Sanity-reference.md for you to refer to, which contains an overview of their docs. If you need a page, just ask me and i will provide it, or use your MCP access. I also included the set up instructions given to me. I have already set up the studio at ......., so use this when creating new schemas etc. Please ask me any questions you need. Please ask me to provide any art, illustrations or designs you may need. Utilise MCP servers if needed. Do not create placeholders, ask me and explain what you are doing and i will provide the correct content that i want Below is the directories to help you understand the project quickly."

Step 6: Watch AND LEARN

Step 7: Complete MVP

Step 8: Implement features incrementally

Step 9: Deploy

Tips:

When there are errors, use @terminal so the LLM can see the error. Also, ensure to include browser console logs and any other logs that may pop up. This makes it much easier to debug.

TDD: test driven development is a common practice where you write tests the software must pass. The LLM adds things to the code until it passes, then refactors once it passes. I havent needed to do this with Gemini yet.

Hand write/type a list of things that need fixing or changing to avoid overwhelming yourself.

When you are picking up a task after leaving your computer for a while, always hit cmd+shift+p then Developer:reload window. Sometimes it glitches across sessions, so this is good practice.

Utilise checkpoints. When you forgot something or the context window is filling up, delete messages/restore the chat to an earlier point. This will free up context to continue. Be aware that you should provide a summary of what you have done, or only delete messages that arent important

"step by step, ferociously"

Project Brief/PRD template:

<role>
Create a projectBrief.md file using the below template. I am your CEO and you are my head engineer. Ask all relevant questions to create an accurate and comprehensive projectBrief.md.
</role>

<template>
# Project Brief: [Project Name Here]

**Version:** 0.1

**Date:** [Date Here]

---

## 1. Project Overview

* **Project Name:** What is the name of your project?

* **Elevator Pitch:** Briefly describe the app/website in 1-2 sentences.

* **Problem Statement:**

* What specific problem does this project aim to solve?

* Why is solving this problem important for the target audience?

* **Goals:** What are the primary objectives for this project? (e.g., Increase sales, provide information, build a community, automate a process)

* **Target Audience:** Who are the primary users? Describe their demographics, needs, and technical proficiency.

* **Success Metrics:** How will you measure the success of this project? (e.g., User sign-ups, conversion rate, engagement time, task completion rate)

---

## 2. Scope & Features

* **MVP Core Features:** List the absolute essential features required for the first functional version (Minimum Viable Product). Be specific.

* *Example: User Authentication: Ability for users to sign up and log in securely.*

* *Example: Habit Definition: Allow users to create/name new habits to track.*

* *Example: Daily Tracking: Provide a simple interface (e.g., checkboxes) for users to mark habits as done for the current day.*

* *Example: Basic View: Display the list of habits and their current completion status for today.*

* *(Add more MVP features as needed)*

* **Post-MVP / Stretch Goals:** List features or improvements planned for after the MVP is successfully launched.

* *(e.g., Habit editing/deletion)*

* *(e.g., Weekly/Monthly view)*

* *(e.g., Reminders/Notifications)*

* *(e.g., Data export)*

---

## 3. High-Level User Flow (MVP)

* Describe the basic journey a primary user takes to achieve the core goal in the MVP.

* *(e.g., User signs up -> User logs in -> User adds a habit -> User views habits for today -> User marks habit complete -> User sees updated status/streak.)*

---

## 4. Key Data / Entities

* What are the main pieces of information the application will need to manage for the MVP?

* *(e.g., User: ID, email, password hash)*

* *(e.g., Habit: ID, user_id, name, creation_date)*

* *(e.g., CompletionLog: ID, habit_id, date, completed_status)*

---

## 5. Technical Specifications

* **Platform:** Is this a web application, mobile app (iOS, Android, cross-platform), desktop app, or something else?

* **Technology Preferences / Constraints (Optional - Can be AI-decided):** Do you have any specific technologies you must use or avoid? Or leave blank/TBD for AI recommendation.

* *Frontend:* (e.g., React with Vite, TBD)

* *Backend:* (e.g., Supabase, Node.js with Express, TBD)

* *Database:* (e.g., PostgreSQL via Supabase, SQLite, TBD)

* *Styling:* (e.g., Tailwind CSS, TBD)

* *Deployment:* (e.g., Vercel, TBD)

* *Other Constraints:* (e.g., Must be installable via Docker)

* **Scalability (General):** Do you anticipate significant user growth beyond the initial MVP target? What are the longer-term expectations?

* **Integrations:** Does the app/website need to integrate with any third-party services or APIs for the MVP? (e.g., Payment gateways, analytics, social logins)

* **Security (General):** Are there overarching security considerations beyond standard practices? (e.g., Compliance like GDPR/HIPAA, specific data sensitivity)

---

## 6. Design & User Experience (UX)

* **Visual Style:** Describe the desired look and feel. (e.g., Modern, minimalist, playful, corporate, luxurious)

* **Brand Guidelines:** Are there existing brand guidelines to follow? (Provide link or details if yes)

* **Logo:** Do you have a logo? If so, please provide it in various formats (e.g., SVG, PNG) or link to assets.

* **Color Palette:** Do you have a specific color palette? Please provide hex codes, swatches, or link to guidelines.

* **Imagery/Photography:** What is the desired style for images or photos? Do you have existing assets, or is stock photography acceptable?

* **Inspiration:** Are there any existing websites or apps you like (or dislike)? What specifically do you like/dislike about them? (Provide links if possible)

* **User Experience (UX) Goals:** What kind of experience should users have? (e.g., Simple and intuitive, engaging and interactive, informative and efficient)

* **Accessibility:** Are there specific accessibility requirements (e.g., WCAG AA compliance)?

* **Wireframes/Mockups (Optional):** Do you have any existing wireframes, mockups, or design files (e.g., Figma links)?

---

## 7. Content Strategy

* **Content Responsibility:** Who will provide the necessary content (text, images, videos) for the MVP?

* **Content Readiness:** Is the initial content ready, or does it need to be created?

* **Information Architecture (Optional):** Do you have an idea of the site structure or navigation for the MVP? (e.g., Main menu items, page hierarchy)

---

## 8. Non-Functional Requirements (MVP Focus)

* Specify critical requirements beyond features for the initial launch.

* **Security (MVP):** (e.g., Standard password hashing, HTTPS enforced, basic input validation)

* **Performance (MVP):** (e.g., Key pages should load within X seconds on desktop/mobile, interactions should feel responsive)

* **Scalability (MVP):** (e.g., Should comfortably handle ~100 concurrent users initially)

* **Reliability/Uptime (MVP):** (e.g., Target uptime for the service)

* **Maintainability:** (e.g., Code should follow standard conventions, include basic comments)

---

## 9. Existing Assets

* **Code:** Is there any existing codebase? If so, where is it hosted (e.g., GitHub repo link)?

* **Designs:** Links to existing design files (Figma, Sketch, etc.).

* **Domain Name:** Do you already own a domain name?

* **Hosting:** Do you have existing hosting arrangements?

* **Other:** Any other relevant materials or resources (e.g., API keys, documentation)?

---

## 10. Timeline & Budget (Optional)

* **Desired Launch Date:** Is there a specific deadline or timeframe for the MVP?

* **Budget:** Do you have a budget range in mind for this project? This helps in prioritizing features and choosing technologies.

---

## 11. Additional Notes

* Provide any other relevant context, constraints, or information not covered above.

</template>