Build Guides

Prompting an AI builder

Builders follow what you write, not what you meant. Give the builder a shape to fill in, and keep each request to one change.

1. Start with one sentence: who it is for and the one job it does.
2. List the screens by name, in the order a user meets them.
3. Name the main things you store and their key fields.
4. Add rules: who can do what, limits, and what happens on errors.
5. End with the style and whether it must work on a phone.

Goal: [one sentence: who + job]
Users: [roles]
Screens: [list in order]
Data: [things and key fields]
Key rules: [permissions, limits, errors]
Style: [look and feel, mobile first?]
Build only the first two screens. Ask me before adding anything else.

Iterating safely

Most wasted credits come from big, vague follow-ups. Change one thing, check it, then move on.

• Save a working version before every large change, and note what worked.
• Ask for one change per message and say what must stay the same.
• When something breaks, paste the exact error and the steps that caused it.
• If the builder loops, roll back and rewrite the prompt instead of patching.

Change only the booking form: add a "notes" field, max 200 characters.
Do not change any other screen, style or data.
After the change, list which files you touched.

Naming things

Consistent names keep an AI builder from inventing duplicates. Pick a word for each concept and reuse it everywhere: prompts, screens, tables and buttons.

• One noun per concept: choose “client” or “customer”, never both.
• Tables are singular nouns, fields are lowercase with underscores.
• Screens are named for what the user does: “Book a class”, not “Page 3”.
• Give statuses a fixed list, such as pending, confirmed, cancelled.

From prototype to production

A prototype proves the idea. Production has to survive real users, bad input and bad days.

1. Freeze the scope. Write down what v1 does and what it does not.
2. Test every screen with empty, long and invalid input.
3. Move secrets out of the code and into the host's settings.
4. Check the app on a small phone and with the keyboard only.
5. Add a way for users to reach you and a plain privacy page.
6. Run the Launch Readiness Checklist below, then release to a few people first.

Worked example: from idea to prompt

Idea: “a booking app for my yoga studio”. A typical first prompt scores low because it names no screens, data or rules. After planning, it looks like this:

Goal: Let yoga studio clients book classes and let the owner see who is coming.
Users: Client, Owner.
Screens: Class schedule, Class detail with Book button, My bookings, Owner attendance list.
Data: Class (title, start time, capacity), Booking (class, client name, email, status).
Key rules: A class cannot be booked past capacity; clients can cancel up to 2 hours before start.
Style: Calm, light, mobile first.
Assumption: no online payments in v1.

Paste a rough idea into the Prompt Lab to get the same structure for your own app.