Everything wired in, as code you own.

These three capabilities run in sequence, and most new projects use all of them within the first few minutes. You start by describing the app in plain English and get a real codebase running on managed infrastructure — not a mockup or a wireframe, but an application you can open and click through. From there you stop writing long descriptions and start pointing: click the element you want changed, say what should be different, or attach a screenshot of a layout you want matched. When it looks right, one click publishes the same app you have been previewing to a public address, with a custom domain if you have one.

The important property of this group is that nothing changes shape as you move through it. The app in the preview is the app that ships; there is no separate export step, no build configuration to reconcile, and no gap between what you approved and what your visitors get.

Both paths sit on the same foundation, and it is the part most people underestimate. Shipping a real application usually stalls not on the interface but on everything behind it: a data layer to write, sign-in to get right, payments to plumb through, row-level security nobody thinks about until it matters. None of that is typed out afresh on every build. The agent works from a catalogue of bricks — six vetted, pre-written modules covering a router and app shell, email sign-in, Stripe checkout, backend middleware, a Supabase data-access layer, and secure-by-default row-level security with the indexes to match. Reaching for one writes real code into your project: the files themselves, the npm dependencies added to package.json, the environment keys appended to .env.example, the SQL migrations, and a set of notes telling the agent exactly where to mount what it was just handed.

That is what pre-wired means here, and it is worth being exact about the half it does not cover. A brick writes the integration; it does not conjure the account behind it. Connecting Supabase, Stripe or Resend is its own explicit step, and for Stripe and Resend it is your account by default — so customers pay you, payouts land with you, and mail leaves from a domain you verified. Either way the code is in your repository, in ordinary Postgres and ordinary Stripe, yours to read and change. The database brick is the clearest case of why that matters: it does not just create tables, it forces row-level security on all of them and indexes the columns the policies filter on.

The second half of the foundation starts where most tools stop. Once a project is live, health checks keep running on its builds, deploys and previews; you are alerted when something breaks instead of hearing it from a user; every project appears in one live view; and every build is kept as a version you can restore the project to. You can read more about the providers underneath all of this on the integrations page.

No capability is much use on its own, and none of them is meant to be. Prompt to app produces something for live preview to refine; live preview produces something for Go Live to publish; Go Live produces something for workspace monitoring to watch. On the other path, code intelligence produces the context the PR agent edits with, and sandbox verification is the gate the pull request has to clear first. The managed backend cuts across both, appearing the moment your app needs data, sign-in, email or money.

Put side by side, the capabilities map almost one-to-one onto the pieces a team would otherwise wire together by hand: a database provider, an auth provider, a sending provider, a payments provider, a host, a deploy pipeline, a CI configuration, and some form of uptime checking. Each is a reasonable choice on its own. Together they are a week you have not spent on the actual product — and a standing maintenance cost every time one of them changes.