Changing a live app
How edits work after the first build, what Keep and Discard do, and what happens to data people have already entered.
Once the app exists, you change it the same way you built it: say what you want in the build chat. Mistflow restores the project, makes the change, runs it back through the same checks, and redeploys.
Asking for a change
Be specific about the outcome, not the implementation:
Add a notes field to each habit, and show it on the detail screen
Make the home screen open on today instead of this week
The streak should reset if someone misses two days, not oneHow many questions you get back depends on the size of the change:
| Change | What to expect |
|---|---|
| Cosmetic | No questions. It just happens |
| A real feature | One or two questions, with a recommended answer already selected |
| New data or a new integration | One proper round of questions |
Keep or Discard
For phone apps, when a change is built and passing, you get to decide:
- Keep — the change becomes the current version of your app
- Discard — the app returns to exactly what it was before
Discard is a real revert, not an apology. It restores the previous version of the source, and the preview goes back to what you had. You get to try a risky change without committing to it and without touching version control.
What happens to data
Changing screens or logic does not touch what people have already entered. Changing the shape of the data can: adding a field is safe, removing or renaming one affects existing records.
If a change would drop data, say so up front and ask for it to be handled, for example
"add a priority field defaulting to normal for the existing tasks".
One edit at a time
While a build or edit is running, a second one is refused with a message rather than queued. This is on purpose. Two jobs editing the same app at once is how apps get corrupted.
The same lock covers an AI editor working on the project. If a teammate is editing in another session, you are told, rather than both edits landing on top of each other.
When an edit seems stuck
Progress is tracked by a heartbeat. If the job actually dies, the edit is closed out honestly instead of sitting at "working" forever. A slow build is not the same as a dead one, and the difference is visible in the build activity.
If an edit does fail, the app is untouched. Failed edits do not half-apply.
The preview after a change
The preview keeps the same link. Live edits reach a running preview without a new QR code, and reopening the app picks up the change. If a preview has gone to sleep or ended, recreate it from the App tab, the link stays the same.
For installed Android builds, a change reaches people differently. See Shipping updates.
Changing the owner console
If your project has an owner console, the build canvas has a Member app and Owner console toggle. That switches what you are looking at.
Changes are applied where they belong based on what you ask for. Directing a change at one specific surface is not something you can do explicitly yet.
Working from an AI editor instead
You can attach Claude Code, Cursor, or Codex to the same project and edit from there. Both sides work from the same source and are serialized by the same lock, so they cannot collide. See Use an AI editor.