Full-Stack Builds (Beta)

Full-stack builds are in Beta. Where a static build produces a website, a full-stack build produces a working web application: user accounts, a database, an admin area, transactional email, and — depending on the product type — bookings, memberships, listings, or a support queue. Everything still lands in your own GitHub repository and runs in your own Render workspace, exactly like static projects.

What a full-stack build includes

• Authentication: email/password sign-up with verification and password recovery, backed by your Supabase project.
• A real database with a migration you can read, and Row Level Security on user-owned tables.
• An admin dashboard for you, gated server-side, matched to the product type (manage services, members, listings, leads, or requests).
• Transactional email (confirmations, status changes) via a Resend-compatible adapter, with an honest simulated fallback when no email key is configured.
• Tests for the product's critical logic, and a deployment configuration for Render.

Supported product types

The Beta supports a specific set of product types where the platform can make reliability commitments: appointment booking, paid membership platforms, customer portals, business directories, simple SaaS dashboards, lead management, internal team tools, AI utilities with accounts, content membership platforms, and lightweight marketplace catalogues. Ideas outside this set can still build as a "custom" application using the closest foundation, but the platform tells you plainly that reliability guarantees are lower there.

How full-stack builds are made trustworthy

A full-stack build does not ask an AI to invent an entire application from nothing. It starts from a human-authored, pre-verified application foundation for your product type, then applies bounded AI customization on top. Every generated file passes safety validation before it can reach your repository — no secrets, no dangerous commands, no unexpected file types — and each build produces a quality report where every item is either a real check or an explicitly labeled estimate. Nothing is presented as verified unless it actually ran.

What "preview" means

Full-stack builds do not go straight to production. The build deploys first to a preview: a separate, temporary deployment on its own URL where you can click through the real application — create an account, make a test booking, open the admin area — before anything is live for your customers.

The approval flow

1. The build finishes and deploys a preview. You get the preview URL.
2. Try the product. If something is wrong, request changes in plain language — a new preview is built.
3. When it is right, approve the preview. Only then does the platform deploy to production.
4. If you reject it, nothing ships, and your notes feed the next attempt.