Build an app from your editor
The end-to-end flow when you drive Mistflow from Claude Code, Cursor, or Codex instead of the browser.
This is the editor version of the Quickstart. The browser path is the front door for new apps; this path is for people who want the project on their machine while it is being built.
What you are building
A team standup tracker: a landing page, a form where people post what they did and what is blocking them, and a feed of today's posts.
Describe it
In your editor:
With mistflow, build me a team standup tracker called "StandupFlow".
A landing page with a hero, a form where team members post their
standup (yesterday, today, blockers), and a feed showing today's
standups. Clean, modern design.Be specific about design and behaviour. "Clean and modern" works; "lots of whitespace, one blue accent, dense feed" works better.
Answer the questions
Mistflow reflects back what it understood and asks a couple of questions, typically who the app is for and whether it needs accounts.
You then get a summary with acceptance criteria for each feature. Those become the feature manifest. If something is missing, say so:
Also add a streak counter for consecutive days someone posted.Watch it build
Mistflow scaffolds the project, installs dependencies, and works through the plan one step
at a time. Components, database schema, styles, and server code land in the project as it
goes, alongside a contracts/ directory that keeps validation in sync with the schema.
See Integration contracts.
Deploy
Once the build is done, it deploys and gives you a URL:
Deployed: https://standupflow.mistflow.appQA
Your editor drives a browser through the acceptance criteria against the live app and reports what passed. Criteria that pass are marked verified in the manifest.
Iterate
Make the form more compact, all three fields in one row on desktop.
And change the accent colour to indigo.Cosmetic changes are edited directly, rebuilt, and redeployed. Larger changes, a new data model or a third-party integration, go through planning first.
Long-running work
Installing, building, QA, deploying, and planning all take longer than a single tool call allows. They use a fire-and-poll shape: the first call returns immediately with a job identifier, and the editor polls until it finishes.
That is why you see repeated tool calls rather than one long silent wait, and why closing your editor does not kill a build.
Tips
- Be specific about design. Reference a look you like rather than adjectives
- Iterate in small steps. Two changes at a time, not ten
- Check what is verified. Implemented is not the same as verified. See the manifest
- Use the dashboard. Build history, deploy logs, and provenance live there