To change an AI-generated app reliably, ask for one specific change per message, name the screen it applies to, and describe the outcome you want rather than the code. Because the builder keeps one file per screen and edits only the file you point at, a request phrased that way changes exactly one thing and leaves everything else untouched. Vague or bundled requests are what cause "it broke something else".
The three-part change request
Screen, change, behaviour. It takes ten seconds to write and it succeeds nearly every time. Compare: "add search" — which screen? searching what? shown where? — and the builder either asks or guesses.
Order of operations
Fix things in this order and you will not redo work:
- Structure — wrong tabs, missing screen, screen that should not exist.
- Data — what is saved, loaded, sent. Getting this right early avoids rewriting screens later.
- Behaviour — rules, calculations, what buttons do.
- Native features — reminders, camera, location.
- Look — colours, spacing, copy. Last, because it is cheap and everything above changes it anyway.
Requests that work
- "On Today, make the habit cards taller with the icon on the left and a big checkmark on the right."
- "In the slot picker, hide slots less than two hours from now."
- "Change the accent colour everywhere from green to #E8562A."
- "On the product page, move Add to cart into a sticky bar at the bottom."
- "Add a Settings screen reachable from the Profile tab with a dark mode toggle."
Requests that waste credits
- "Make it look more professional." (No instruction. Say what: spacing, colours, fewer borders, bigger headings.)
- "Redo everything with a better design." (Regenerates every screen; costs the most and loses your earlier fixes.)
- "Add all the features a real app would have." (Unbounded.)
- "Fix the bug." (Which one? Describe what you tapped and what happened.)
Describing a bug
Three sentences: what you did, what you expected, what happened. "On Order, I tapped Confirm with an empty basket. I expected a message. The screen went blank." The builder can reason from that; it cannot reason from "checkout is broken".
Undo and versions
Every generation is a step you can go back from. If a change made things worse, undo it and rephrase rather than piling a correction on top of a correction — stacked corrections are how a screen becomes a mess. Export at milestones ("v1 — menu and order working") so you always have a copy that builds.
When to start over
Rarely. Start a new project only when the structure is wrong — the app turned out to need a different first screen or a different set of tabs. Then write a fresh prompt using what you learned; the second prompt is always better than the first. Do not start over for look-and-feel; that is always fixable in place.
Keeping the cost down
Credits are charged by tokens, so cost tracks how much the builder has to read and write. Short, targeted requests cost a handful of credits; "look at the whole app and improve it" costs many. Edit plain text — menu items, prices, labels — yourself in the project's data files, which costs nothing. See what it costs.