How it works
The stages an app moves through, from a sentence on /create to something installed on a phone.
Every Mistflow app follows the same path. Knowing the stages tells you where you are when something takes a while or comes back wrong.
idea → prototype screens → shaping → make it real → build
→ verification → live preview → change it, forever1. Prototype
You describe the app. Mistflow works out who the app is for and what jobs they are trying to get done, names it, picks a look, and renders the screens. Screen one is built around the main job.
Nothing is running yet. There is no database and no sign-in, and an "AI coach" screen is a picture of a coach. The prototype exists so you can disagree cheaply, before any code is written.
2. Shaping
You change the prototype until it matches what you meant. Edits fall into two kinds:
- Instant — restyling, reordering, renaming, swapping a screen's layout. No waiting.
- Generated — adding a screen, changing content, relaying out a screen. A few seconds.
Every edit tells you honestly whether anything changed, and declines rather than pretending when you ask for something the prototype cannot express.
3. Make it real
Signing in claims the prototype into your account and turns it into a build specification: the screens, the decisions you made while shaping, the starter content, and who the app is for.
Then you get a short round of questions, deliberately limited to what a picture cannot answer. Do people need accounts. What must be true about the data. Who is allowed to see what. Screens, features, and styling are already settled and are not re-asked.
4. Build
The build runs on Mistflow's servers in an isolated sandbox. Your approved screens are laid into the project directly rather than being redrawn from a description, so the app you get looks like the prototype you approved.
Builds are durable. Closing the tab does not cancel one, and progress survives a reload. A phone build takes longer than a web build because there is more to compile.
Only one build or edit runs against a project at a time. A second one is refused with an explanation rather than queued behind the first.
5. Verification
This is the part most tools skip. Before you are handed anything:
| Check | What it catches |
|---|---|
| Compile | Code that does not build |
| Boot | Builds that compile but show a blank or crashed screen |
| Fidelity | Drift from the prototype you approved: wrong name, wrong tabs, wrong accent |
| Run check | Crashes that only appear on a real device, on a real Android emulator |
The run check boots an emulator, installs Expo Go, opens your app as a brand-new user, signs up, taps through the tabs, and reads the crash log. If the app crashes there, the build does not get to call itself ready. See What gets checked.
6. Live
For a phone app, "live" means two things:
- The app — a preview you open in Expo Go on a real phone, by tap or QR code
- The web half — a small site for your app, used for links, sign-in redirects, and store compliance
The web half is the app's website, not the app.
7. Changing it
You keep talking to the build chat. Mistflow restores the project, makes the change, rebuilds it through the same gates, and redeploys. For phone apps you get Keep or Discard on the result.
The rules it follows when you ask for something:
- Cosmetic change: no questions
- Real feature: one or two questions with an answer already selected
- New data or a new integration: one proper round of questions
Where the code lives
The canonical copy of your app is stored by Mistflow and is what every build, edit, and recovery works from. You can download it, and you can attach an AI editor to the same project and work on the exact same source. Server-side edits and editor-side edits are serialized so they cannot collide.