How to Vibe Code a Feature or a Complete App
It’s never been easier for entrepreneurs to build new things. If anything, the big challenge now is what to build.
Here are my recipes of carefully written prompts for ChatGPT + Cursor for:
- Building a new feature in an existing app.
- Building a complete app* from scratch.
(*App here can be either a web app or a mobile app)
Note: my workflow and many of the instructions are heavily inspired by @swestinmotion’s post.
General code guidelines
You want some general code guidelines. You’ll probably define these as Cursor rules or similar, but I actually slap on a short version of them on the IDE prompts (see below).
Example guidelines:
- Write the absolute minimum code required
- No sweeping changes
- No unrelated edits - focus on just the task you’re on
- Make code precise, modular, testable
- Don’t break existing functionality
- If I need to do anything (e.g. Supabase/Google/AWS config), tell me clearly
Building a new feature in an existing app
Step 1: tasks.md
Open ChatGPT (4o, not o1/o3/o4) and say:
I’m building a [description of your feature, details, tech specs]
Write a granular step-by-step plan to build this feature. As markdown, and name it tasks.md
Each task should:
- Be incredibly small + testable
- Have a clear start + end
- Focus on one concern
I’ll be passing this off to an engineering LLM that will be told to complete one task at a time, allowing me to test in between.
Step 2: In your IDE (e.g. Cursor/Windsurf)
You’re an engineer building a new feature. You've been given @tasks.md
- Read @tasks.md carefully. There should be no ambiguity about what we’re building.
- Follow tasks.md and complete one task at a time.
- After each task, stop. I’ll test it. If it works, commit to GitHub and move to the next.
- Write the absolute minimum code required
- No sweeping changes
- No unrelated edits - focus on just the task you’re on
- Make code precise, modular, testable
- Don’t break existing functionality
- If I need to do anything (e.g. Supabase/Google/AWS config), tell me clearly
Building a complete app from scratch
Step 1: Feature list
Before diving into the details, I want to be sure that the AI and I are aligned on a vision for what the app should be.
I normally go for just a feature list, but you could go deeper here and create a full Product Requirements Document (PRD).
I’m building a [description of your product - the more detailed the better]
Give me a feature list for the MVP of this product in 10-20 bullets. One row per bullet. Avoid emojis.
Step 2: architecture.md
Open ChatGPT (4o, not o1/o3/o4) and say:
I’m building a [description of your product - the more detailed the better].
Technically, I want [you to suggest something, or: Next.js for frontend, Supabase for DB + auth. Postgres, TypeScript, React, shadcn/ui, Tailwind, Vercel, OpenAI Assistants API with Vector Stores]
Design-wise, I want it to be [colorful and bold, think Basquiat meets Jony Ive].
Give me the full architecture:
- File + folder structure
- Base version of OS or Node
- What each part does
- Where state lives
- How services and APIs connect
- Structure and guidelines for design system (colors, fonts).
Format this entire document in markdown, call it architecture.md. Avoid emojis.
Save its output as architecture.md and put it in an empty folder where your project will live.
Step 3: tasks.md
Read this feature list and @architecture.md. Write a granular step-by-step plan to build the MVP. In markdown, call it tasks.md. Avoid emojis.
Each task should:
- Be incredibly small + testable
- Have a clear start + end
- Focus on one concern
I’ll be passing this off to an engineering LLM that will be told to complete one task at a time, allowing me to test in between.
Save it as tasks.md. Again, put it in the project folder.
Step 3: In your IDE (e.g. Cursor/Windsurf)
You’re an engineer building this codebase.
You've been given @architecture.md and @tasks.md.
- Read both carefully. There should be no ambiguity about what we’re building.
- Follow tasks.md and complete one task at a time.
- After each task, stop. I’ll test it. If it works, commit to GitHub and move to the next.
- Write the absolute minimum code required
- No sweeping changes
- No unrelated edits - focus on just the task you’re on
- Make code precise, modular, testable
- Break out into multiple files when needed
- Don’t break existing functionality
- If I need to do anything (e.g. Supabase/Google/AWS config), tell me clearly
