What happens after you describe the first screen?

Dyad proposes code for your app. In standard Build mode with manual approval, approving changes saves the files and can start a preview on your computer.

Start with a screen that counts items packed for a pretend event. Install the desktop app and follow its setup prompts. The preview needs Node.js, the software that runs the project. Dyad can set up a compatible runtime for supported previews. Follow its manual setup guidance if it cannot. Give Dyad access to a model you are permitted to use. The first preview may install software packages the generated app depends on, so approval can start more than a visual preview.

What stays on your computer?

Your source files stay in a local project. What happens to the text and code you share with the builder depends on the model you select.

Dyad supports models running on your device through Ollama or LM Studio. Larger models may need more memory. If you supply your own key for an online model, Dyad says it sends prompts and selected code to that provider. Its paid hosted-model service sends that material through Dyad as well. Use a workspace and model you are allowed to share with, and leave credentials and real records out of the sample.

How can you check one local change?

Use a small, disposable tally with no account system, database or outgoing actions. You can compare its expected behavior on paper before running generated code.

Prepare the sample before building
Use a new disposable folder with only invented files. Check that it has no production configuration, Git remote or connected services, and use only model access you are authorized to use. Before sending the prompt, choose Build mode, turn off automatic approval and leave connected tools disabled. If you cannot confirm that Dyad will wait for your approval before applying changes, keep the exercise on paper.
Describe the expected result
Ask for one screen with a count that starts at zero, a button that adds one, and a Reset button that returns it to zero. Ask for temporary screen state only. Leave out storage, sign-in, new packages and network calls.
Review before approving
Inspect the proposed files and dependencies before approval, since approval can run the app. If you can verify the sample only changes the tally, preview it. Two presses should show 2 and Reset should show 0. If you cannot verify the proposed code and what it runs, keep the two checks on paper.

How does a local project become a site others can visit?

Publish the project through a separate host. Dyad documents syncing the source to GitHub and connecting that repository to a web host.

The tally needs no shared records. For an app that lets people sign in and see their own requests, Dyad documents a separate Supabase connection. Use a test project first and review the rules that decide which records each person can read or change. A hosted preview can still point to a live service, so check the actual connections before you open it.

Dyad’s version history can restore the code to an earlier state. Keep a separate backup and recovery plan for records, uploaded files and account settings held by the services you connect.

What will you pay for, and what can you keep?

The desktop Free plan supports your own model access. The public Pro and Max subscriptions are monthly and list 200 and 900 monthly AI credits respectively, checked November 12, 2026.

If you use your own online model key, check that provider’s usage limits and charges. A model on your computer uses your machine’s resources. Website hosting and any connected database have separate limits and billing.

Keep the project folder or a private repository copy so another editor can work on the same files. Before switching builders or hosts, list the external connections and the records they hold. The project copy alone will not restore them.