The project stays local, but the intelligence comes from elsewhere
Dyad is a desktop workshop for making web apps through chat. You describe a feature, inspect the result in a built-in preview, and keep the generated project on your machine. That last part is the useful distinction from browser-only builders: the working files are local, and the README says you can bring your own AI API keys. The application itself does not turn a laptop into a local language-model server.
The downloadable product targets Mac and Windows. Underneath, it is an Electron application with a TypeScript codebase and a local database stored under userData. Contributors need to create that directory before starting the app. The package declares Node 24 or 25, while the development commands use npm. For a person who wants to install an app and start prompting, that machinery stays mostly out of sight. Anyone changing Dyad itself gets the full desktop stack.
The license changes at src/pro
Most of the repository uses Apache-2.0, but the README draws a bright line around src/pro. That directory uses Functional Source License 1.1 with an Apache-2.0 future license. The contributing guide also says that contributions inside src/pro take that license. A company with an Apache-only intake rule cannot approve the repository by glancing at the root license file.
This split does not prevent normal use of the downloadable app. It does change what "open source" means across the checkout, especially for anyone planning to modify, redistribute, or build around Pro code. Read both license files before assigning engineers. The GitHub API reports the root license as NOASSERTION, which is another reason to review the directory boundary directly rather than depend on a metadata badge.
What happened when we ran it
Our sandbox installed commit fd562c6 in 110 seconds. npm added 1,594 packages, and the installed tree occupied 2,168 MB. The build then succeeded in 187 seconds inside an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The checked-out repository itself contained 3,664 files, about 657,595 lines of source, and used 34.7 MB.
The test command failed after 548 seconds. Vitest reported 9,099 passing tests, 10 failures, and 12 skipped tests out of 9,121. Each failure shown in the tail was a 5,000 ms timeout. The summary counted 74 failed test files, even though only 10 individual tests failed, so the file count should not be read as 74 distinct broken assertions.
The tail also printed expected error cases from search_replace_dsl.spec.ts, including case mismatch, missing context, repeated matches, and an empty original file. Those lines were on stderr, but the supplied tail does not identify them as the 10 timed-out cases. We cannot honestly connect the timeout to a specific subsystem from that excerpt. The finding is simply that the complete command did not finish cleanly on commit fd562c6.
npm audit found 96 known vulnerabilities: 7 critical, 55 high, 17 moderate, and 17 low. That count belongs to the dependency tree we installed, not a claim that 96 flaws are remotely exploitable through Dyad. It is still too large to wave through a strict software-supply-chain gate. A prospective adopter should inspect the affected packages and reachable paths before making a risk decision.
Mac and Windows get the documented download path
The README promises a no-sign-up download and names Mac and Windows. Linux is absent from that platform list, although the contributor instructions include Unix commands for creating userData. That makes source development and an officially advertised desktop package two different questions. Linux users should verify their intended path before treating Dyad as a cross-platform team standard.
Model access is another boundary. Bring-your-own-key support reduces dependence on a single AI vendor, but it does not remove hosted-model credentials or usage costs. Recent v1.17.0 notes added ChatGPT subscription support and an experimental Claude Code integration. Publishing features also mention Vercel and Cloudflare work, while Supabase appears throughout the current issue and release activity. Each service introduces its own account, permissions, and failure modes.
The October 1 push shows a busy project with a busy queue
GitHub recorded 21,631 stars, 308 open issues and pull requests, and a last push on October 1, 2026. Release v1.17.0 arrived on September 28 with a long list of fixes and additions. The release included test-isolation changes, a fix for an unresponsive MCP server freezing agent chats, Cloudflare publishing, and the experimental Claude Code work. This is active maintenance, not a repository coasting on an old tag.
The same pace brings churn. Open reports around the release include chats becoming stuck and built-in preview behavior differing from external browsers. These are user reports, not results from our container, and issue counts combine pull requests with issues. Still, a product that edits code, runs previews, connects model accounts, and publishes apps has a broad failure surface. Teams should test their chosen model and deployment route rather than treating the green build alone as acceptance.
Dyad is best for local visual building, not CI-first engineering
Bolt.diy is the closer pick when you prefer a browser workspace. OpenHands makes more sense when an agent needs to work through an existing repository rather than shape a new app in a visual builder. Open Lovable is narrower still: it starts from a live website and recreates it as React. Dyad earns its place when the local desktop loop is the reason you are choosing the tool.
That loop worked well enough for our build to finish, but the engineering bill is visible: 1,594 packages, 2,168 MB after installation, 96 audit findings, and a suite that stopped with 10 timeouts. For an individual builder, those costs may sit behind the installer. For a team adopting or extending the codebase, they belong in the decision before the first generated app reaches production.