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 each screen separate and edits only the screen 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 AI tokens
- "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. Build an APK at milestones ("v1 — menu and order working") so you always have a working copy on your phone. You can also type "undo" to roll back the last change.
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
Your OpenAI bill tracks how much work the builder does. Short, targeted requests use few tokens; "look at the whole app and improve it" uses many. Changes that need no AI cost nothing: the design pickers for the bars and side menu, and the web admin for products and menus in shop and restaurant apps. See what it costs.