Dyad

You will like Dyad because the builder is a desktop app, and that changes the daily rhythm: the project is a folder on your machine, the preview runs locally, and you can open the same folder in your own editor to fix what the agent got wrong. Nothing leaves your disk unless you push it.

What you give up is hosted convenience. There is no vendor-run deploy button, so the last mile to production is yours to wire. Pick it if you want the code under your hand from the first prompt. Pick Lovable when you need a link to send by dinner.

The risk is unverified output. terminal_exec is false, so the agent cannot install a dependency, run a build or execute a test; it writes files and shows a preview. A broken import surfaces when you run the project, not when the agent does; the preview only exercises the paths you click.

The consequence is that every generation needs a human build step before it counts as done, fine for a prototype, expensive with a test suite. A terminal tool with test execution would change this verdict. What it does right: the MCP write-up states plainly that servers add dependencies and that queries go to those services.

Dyad publishes no benchmark. The architecture inverts the category. 1. Output is runnable Next.js written to a local directory, not an artifact held on a vendor's host. 2. Backend and deployment are integrations chosen by the user, Supabase or Neon for data, Vercel for hosting, GitHub for history, so no layer of the stack is proprietary to the builder.

The consequence for verification is that the user's own toolchain, not the agent, is the check: the exported tree compiles or it does not. The observation: an app builder that exports first has nothing to hold hostage, and nothing to measure either.

A small company with a large repository, 21,377 stars, and a monetization layer that sells hosted credits: Pro at $20 for 200 credits, Max at $79 for 900. That is a convenience margin, thin by design, because the customer can always route around it with a key of their own. The moat is the community, and community is not revenue.

The likely acquirer is an infrastructure vendor that wants the front door, whoever sells the database the generated apps land on. The pivot, if it comes, is toward the hosted side. Position: use it, expect the credits to get pricier and the local path to stay free.

The demo is an app builder on a laptop. Procurement finds nothing to buy at team scale: the plans page lists individual tiers only, no organization plan, no SSO, no SCIM, no audit trail, and no retention statement, because the vendor never sees the code. That last point is a security answer and a procurement problem at once.

Sixty installs means sixty local configurations, sixty sets of API keys pasted into a desktop app, and no central spend limit on any of them. Onboarding is easy, governance is absent. What would change the verdict is an organization tier with managed keys and a usage report. Not yet.

Mostly mine. The core is Apache-2.0 with one carve-out, the src/pro directory under its own license, and the carve-out is labelled rather than hidden, which is more than most dual-license projects manage. Providers include Ollama and LM Studio, so it runs against my own box, plus OpenAI, Anthropic, Google and OpenRouter keys when I want a bigger model.

MCP servers install from dyad.sh/hub with an Add to Dyad button, stdio or HTTP, so my existing servers attach without a rewrite. The consequence: a fork survives the vendor, minus the Pro directory, and everything I depend on is in the open half. Grudging respect for the honest carve-out.