Local ownership is the reason to choose Dyad
Dyad takes the prompt-to-app experience popularized by Lovable, v0, and Bolt and puts it in an Electron desktop application. Describe a product, watch the model generate files, and inspect the result in a live local preview. The project directory belongs to you, not a hosted workspace, and the free route does not require a Dyad account. You can bring model access rather than accepting one bundled AI vendor.
That is a meaningful difference for makers who want a fast prototype without giving up ordinary code ownership. Files can be inspected in an editor, committed, connected to GitHub, and deployed through familiar services. Version history lets a user step back when a prompt makes the app worse. Visual component selection and editing reduce the need to explain every change in prose. Integrations cover databases, deployment, repositories, and an MCP plugin catalog.
Dyad is aimed at nontechnical builders first, according to its own product document, with semi-technical users as a secondary audience. The interface tries to translate Node, ports, package installation, and model configuration into guided tasks. That is the right goal. The application still creates software, though, and generated software eventually demands software judgment.
Local does not necessarily mean private inference
The app, generated files, and preview run locally. The model may not. With a cloud model, prompts and supplied context travel to that provider. Dyad's architecture document says the default request includes the entire codebase alongside the user's instruction and a system prompt. Small projects benefit because the model sees relevant files without a search step. Large or sensitive projects should stop and assess what is being sent.
Users can manually narrow context, and the Pro Smart Context feature uses smaller models to select important files. The documented free architecture otherwise favors whole-project context. That can raise token cost as an app grows and may cross a company's source-handling policy. Bringing your own key also means bringing your own bill, rate limits, retention terms, and incident response.
Local models can improve data control, but their code-generation quality, speed, and hardware needs vary. The practical promise is choice and local project custody, not automatic air-gapped development. Dyad should make this distinction prominent because “local” is easy to read as “nothing leaves this laptop.”
The editing loop is intentionally understandable
The classic build mode asks a model to return special XML-like instructions for writing or deleting files and adding packages. Dyad streams those instructions into a readable interface, then its privileged main process applies approved changes. This approach works across models that differ in formal tool-calling support and can express several edits in one response.
A newer local agent uses standard tool calls in a repeated loop. The agent architecture lives under src/pro, and release 1.9.0 added test-running behavior, chat-history tools, MCP catalog improvements, state-machine work, and safer Git operations. The release notes show extensive effort around concurrent chat, previews, OAuth, user input, and undo or retry behavior. Those are not decorative additions. They address the messy lifecycle problems that appear when an AI edits a live project while the user can cancel, switch, or restore state.
The product still cannot replace a developer's verification. Open issue #4224 explains that generic shell commands such as npm test are unavailable, and Dyad's automatic commits can collide with custom pre-commit hooks. A curated test tool is useful, but projects with unusual build, lint, migration, or code-generation steps need manual execution. Never treat a successful preview as proof that authentication, permissions, mobile layout, accessibility, tests, and production builds are correct.
Open source has an important boundary
The README calls Dyad open source, then states a split license. Everything outside src/pro uses Apache 2.0. Pro code uses Functional Source License 1.1 with an Apache 2.0 future license. The FSL permits internal use, education, research, and professional services for a compliant licensee, but it prohibits using that code in a competing commercial product or service. Each version moves to Apache 2.0 after two years.
This is transparent and more inspectable than a closed hosted builder, but “all open source” would be inaccurate today. Companies embedding, redistributing, or building a competing service must identify which code they need and review the terms. Ordinary users building their own applications are not the obvious problem case. Platform vendors are.
Young, fast-moving, and not yet boring
Dyad was created in April 2025 and has already attracted more than 21,000 GitHub stars. The repository was pushed on August 10, 2026, while version 1.9.0 shipped July 27. Its 275 open items combine issues and pull requests, and many session reports are incomplete, so the number is not a clean defect count. Current commits, releases, and triage show a healthy project moving very quickly.
The rough edges are concrete. Issue #4171 says a branch deleted on GitHub can remain in Dyad's local branch list. Issue #3727 says GitHub sync may report success despite uncommitted files. Recent open reports also cover updater failures on Windows and macOS, while several duplicates were closed. These problems do not erase the local-first advantage, but they argue for checking the actual repository state in Git before trusting a reassuring toast.
Dyad is a strong prototype workbench, especially for someone who dislikes hosted lock-in and wants files they can open normally. It is not a magic path from idea to maintained production service. Start a small app, use a model whose data policy you accept, review every integration credential, and add normal tests outside the preview loop. If the generated project survives that handoff, Dyad has done its job well.