From PRD to App: A Vibe Coding Workflow That Actually Works
How to write a one-page PRD that AI understands, plus a 6-step workflow that keeps your app stable across many rounds of changes.
Many people start vibe coding with a single sentence, "build me an ordering app", and get a good-looking screen within minutes. But after ten rounds of changes the app starts drifting: buttons that used to work break, and data is not saved properly. Most of the time the cause is not the AI. It is that we never said clearly, from the start, what we were building. The fix is a short PRD and a step-by-step workflow.
What is a PRD, and why does vibe coding need one?
A PRD (Product Requirements Document) states what problem the product solves, for whom, what it does and what it does not do yet. In vibe coding, the PRD acts as the main context the AI comes back to every time. An LLM does not perfectly retain your intent across a long conversation; the longer you chat, the more early details fade. A shared document pulls everything back to the same place.
A one-page PRD structure that works
What to include
- Problem: who has it, how often, how it is handled today
- Users and roles: for example customer, owner, staff, and what each role can see
- User stories: written as "As a... I want to... so that..."
- Data to store: which tables, which fields, how they connect
- Main screens: a list is enough, no drawings needed
- Out of scope: what you are not building this round, which stops the AI from adding extras
- Acceptance criteria: the conditions that mean a feature is "done"
Let AI draft it, but you make the decisions
Describe the problem in plain language and ask the AI to draft a PRD using the structure above. Then ask it to "ask me 10 questions about anything that is still unclear". This step often reveals things you never considered, such as whether customers can cancel an order, or what happens when an item is sold out.
A 6-step workflow from PRD to app
Step 1: Plan before building
Give the PRD to your tool and ask for a "build plan" first, without writing code. Some tools have a planning or chat mode separate from the editing mode. If yours does not, say it directly: "Do not edit any files yet. Give me a step-by-step plan first."
Step 2: Build the skeleton and data
Start with the main layout, login and the data structure before visual details, because changing the data structure later usually affects many pages.
Step 3: Build one vertical slice at a time
A vertical slice is one feature built end to end, from the screen to saving the data, for example "a customer can order a cake and the owner sees the order". Finishing one slice at a time beats building every page halfway.
Step 4: Test against acceptance criteria
After each slice, check it against the conditions in the PRD. Try odd cases too, such as empty fields or double-clicking a button.
Step 5: Keep restore points
When a slice works, save a version (for example by connecting GitHub or using the tool's version history). If the next round breaks something, you can go straight back to a good state.
Step 6: Update the PRD
Whenever you decide to change something, update the PRD too, so the document always matches the real app.
Example: a home bakery in Khon Kaen
The owner takes orders through chat and often misses details. She writes a one-page PRD: customers choose a cake design, size and pickup date, and can attach a reference photo; the owner sees orders sorted by pickup date. Out of scope: online payment for now. When the AI asks back, "How many days in advance can people order?", she realises she needs to close dates when the queue is full and adds it as a new user story. The result is an app that matches the real work from the first round instead of being rebuilt later.
One clear page of instructions beats ten rounds of fixes.
Things to watch out for
- Do not put real customer data, passwords or API keys in the PRD, because this document is sent to the AI over and over
- State clearly in the PRD who can see what, for example customers see only their own orders. If you do not, the AI may build pages where everyone sees everything
- Features involving money or personal data should be their own slice and be reviewed by someone who understands the system
What to do next
- Pick one idea and describe the problem and users in 5 lines
- Have the AI draft a PRD using the 7-part structure, then ask it to question you back
- Cut the features down to 2 to 3 slices for the first version
- Build one slice at a time, test, and save a version each time
If you are still unsure what vibe coding is, start with What Is Vibe Coding. And if you want to know which career paths this kind of requirements-writing skill can lead to, try the Plants.work AI Career Assistant to explore paths that fit you.