Lesson 2 of 5 · Build apps with AI · 8 min read
How to prompt an AI app builder
Write AI app prompts that protect working screens, clarify vague requests and produce testable results. Includes first-build and revision templates.
Visual guide. The walkthrough compares a vague request with a task-shaped prompt, names what must stay, shows current Build, Plan mode and Bug fix mode choices, then highlights the only changed hero region.
Read the video transcript
A useful prompt names the person, the job they need done and the point where the journey is complete.
Add the screens, information and business rules the first version must respect.
Tell Grafter what to preserve before asking for a revision, so a hero change does not rewrite the whole app.
Use Plan when the request is still fuzzy; use Build when the outcome and boundaries are clear.
Read the preview, then ask for the smallest change that fixes the next visible problem.
🧠 The useful prompt formula
A strong app-building prompt answers five things: who is using the app, what they need to finish, what information moves through the journey, which rules cannot be guessed and what visible result means done. That is enough structure for the agent to make design decisions without inventing the business.
You do not need to sound technical. ‘A customer chooses a repair, uploads three photos and gets a reference number’ is more useful than ‘build a scalable service platform’. The first sentence can be turned into screens and tests. The second is a mood.
Person + job + information + rules + done
- Person
- The first real role: customer, member, staff dispatcher or coach.
- Job
- The action that makes opening the app worthwhile.
- Information
- What they enter, choose, calculate, save or need to see again.
- Rules
- Prices, permissions, availability, required fields and honest limits.
- Done
- A confirmation, saved item, changed status or other observable ending.
1. Write the first build as a small product brief
Start with the outcome, then name the screens and interactions needed to reach it. Give real copy and business rules where they affect trust. Finish with the features that are deliberately out of scope, because silence is often read as permission to add a dashboard, social feed or sign-in wall you never asked for.
This example builds an internal job board. It includes enough fictional seed data to make the states visible, but it refuses fake customer claims and external actions. Swap the nouns and rules for your business; keep the boundaries.
2. Use Plan, Build and Fix for different jobs
Use Plan when the idea still contains a real fork: perhaps the app could be a booking tool or a quote-request tool, and that choice changes the screens. A useful plan names the proposed journey, uncertain decisions and what will be left for later. It should not spend a page pretending certainty.
Use Build when the desired result and boundaries are clear enough to edit files. Use Fix when something that should work does not: a button is dead, the phone view clips or the preview crashes. A fix request needs the observed failure and the shortest reliable way to reproduce it.
| Mode | Give it | Expect back |
|---|---|---|
| Plan | Goal, audience, open decisions and constraints | A proposed route with questions that materially change it |
| Build | Target, visible result, rules and preserved parts | A completed edit plus a preview you can check |
| Fix | Observed fault, steps, expected result and current result | The cause repaired without an unrelated redesign |
3. Fence every revision before the agent edits ✍️
A revision prompt should be narrower than the first prompt. Name the screen or component, describe what is wrong, state the visible correction and list what must stay. This protects good work and gives the agent a small acceptance test.
Suppose the request is ‘change the hero image’. A careful agent should keep the headline, buttons, layout and other pages unless the image change makes one of those impossible. If the replacement itself is unclear, it should offer a few meaningful choices—real photo, illustration or existing uploaded image—instead of quietly redesigning the hero.
Tip. For a vague section request, offer options only when choosing between them changes the build. Three concrete choices beat a blank ‘can you clarify?’ and beat an unapproved redesign.
4. Answer the questions that change the product
A good agent does not turn every sentence into an interview. It asks when two plausible interpretations would produce materially different screens, data or risk. The best question carries its own useful options and recommends a default.
If you ask for ‘a dashboard’, it may need to know whether the first view is for the owner, staff or customer. If you ask to ‘add payments’, it needs to know what is sold and whether the charge is one-off or recurring. If you ask for a blue header, it should make the blue header.
Example: a vague header request
Request: ‘Make the header better.’ A useful response narrows the decision without blocking progress.
- Compact utility header—logo, one primary action and no extra navigation (recommended for the app).
- Marketing header—logo, page links and one strong sign-up action.
- Workspace header—project switcher, status and account controls.
Example: a vague payments request
Request: ‘Connect payments.’ The agent should first surface the commercial choice and guide the secure connection.
- One-off product checkout—best when the buyer receives one named item.
- Deposit—best when a booking is held and a balance is paid later.
- Subscription—best only when access or service genuinely repeats.
5. Give the agent evidence it can actually use
Attach the logo, image or document when the request depends on it. Name the file and the screen where it belongs. When correcting a visual fault, say what you see in the preview: ‘the orange button sits outside the white card at phone width’ is evidence; ‘it feels off’ still leaves the agent guessing.
For copy, paste the approved wording rather than asking the builder to recreate a policy, price or legal promise. For a workflow, include one realistic fictional example and one failure. Examples make empty states and long labels visible before real people discover them.
- A screenshot with the broken area named.
- The exact text, price or business rule that must be used.
- The route, screen or component that may change.
- The current result and the expected result.
- The parts already working that must be preserved.
6. Keep secrets and live customer data out of prompts 🔐
Do not paste passwords, private API keys, live card details or customer records into a prompt. A payment, email or database connection has a proper secure setup. Ask the agent to guide that setup, then enter credentials only in the provider or protected settings field intended for them.
A screen can be built before its service is connected, but its wording must stay honest. ‘Connect Stripe to activate checkout’ is truthful. ‘Payment complete’ on a button that does nothing is not a placeholder; it is a false result.
Note. If a secret has already been pasted into source, chat or a public repository, treat it as exposed: revoke or rotate it at the provider rather than merely deleting the visible copy.
When the result is the opposite of the request
Stop adding new design instructions. Return to the last version where the unaffected parts were correct, then restate the edit with a target and preserve list. Mixing a repair with more taste changes makes it harder to tell which instruction caused the damage.
Write the correction as an observable difference: ‘restore the original headline and button; replace only the image file’ is testable. ‘Undo the weirdness’ is not. Check the affected file or screen after the edit, then replay the one journey that passes through it.
- Name the last version or visible state that was correct.
- List what changed that should not have changed.
- State the one remaining change you still want.
- Tell the agent what must be restored and preserved.
- Verify the exact screen at phone and desktop widths before continuing.
Common questions
- How detailed should an AI app prompt be?
- Detailed enough to name the person, central journey, information, rules and finish line. Leave ordinary visual decisions to the builder unless a colour, asset or layout is a real requirement. Add boundaries for features that should not appear yet.
- Should I put every feature in the first prompt?
- No. Include what is needed for one complete journey. Keep future ideas in a later list so the first build can be used and tested instead of spreading effort across empty screens.
- Why did the AI change parts I did not mention?
- The target or preserved boundary may have been unclear, or the edited component may be shared. Name the exact screen or component, state what must stay and ask for a post-edit check of the affected journey.
- When should the app builder ask me questions?
- When two reasonable interpretations would materially change the screens, data, cost or risk. The question should include a small set of concrete options and a recommended default, then stop asking once the decision is clear.