The App Builder: a chat-first AI IDE
The App Builder is Mass's code-native builder — describe what you want and it writes the real files, runs them live in your browser, and lets you refine by chat, by clicking elements on the preview, or by editing the code directly. It builds funnel pages against your launch checklist, stays on-brand through the Context Engine, and ships to platform hosting, a host of providers, or straight to GitHub.
20 min read · The complete App Builder guide
What the App Builder is
A real IDE with AI at the helm — it writes actual files, not a closed page model.
Most builders hand you a fixed component model and let you fill in the blanks. The App Builder is different: it generates a real project — HTML, CSS, and JavaScript, or a full Next.js / Vite-React app — and runs it live in your browser. You drive it by describing what you want in chat, and it responds by creating and editing the actual source files, which you can read, edit, and own.
Because the output is real code, there's no ceiling: you can build a landing page, a multi-page funnel, an interactive tool, or a small web app, then publish it to Mass's hosting, deploy it to your own Vercel/Netlify/Cloudflare account, or push it to GitHub. And because it's part of Mass, it shares your brand tokens and offer context, and plugs into the same launch checklist that drives the rest of your onboarding.
- Real code — generates actual project files — vanilla HTML/CSS/JS or a Next.js / Vite-React app — that you can read, edit, and export.
- Chat-first — describe a change in plain language and the AI writes or patches the files; drop into the code editor anytime to do it by hand.
- Live preview — everything runs instantly in an in-browser WebContainer with a real terminal — no local setup, no deploy step to see it.
- Connected — shares your brand and offer context, builds funnel pages against your launch checklist, and publishes anywhere.
Two stacks, one workflow
Pick a no-build vanilla HTML/CSS/JS project that runs directly in an iframe, or a framework project (Next.js / Vite-React) that boots a dev server in a WebContainer. The chat, visual editing, and publishing flow are the same either way.
From description to working app
A multi-pass pipeline plans the work, writes the code, then critiques its own output.
When you send a prompt, the builder doesn't just dump code. For non-trivial requests it runs a planning pass first — deciding which files to create or change and in what order — then a generation pass that streams the actual file writes, and finally a critic pass that reviews the result and flags issues to fix. You watch it happen live: a status bar narrates each phase, and files light up in the tree as they're written.
The AI writes files using a structured action format under the hood, so the builder can apply full-file writes for new or small files and surgical patches (unified diffs) for edits to larger ones — which keeps long files from being truncated or corrupted. Everything streams into the preview as it lands, so you see the app take shape in real time rather than waiting for a final result.
- Planning pass — for bigger requests, the AI first lays out which files to touch and in what order before writing anything.
- Generation — streams real file writes (and surgical patches for large files) straight into your project and preview.
- Critic pass — reviews its own output, catching issues so the next turn can fix them.
- Live status — a status bar narrates reasoning, writing, and continuation; the file tree shows exactly what changed.
The workspace: editor, preview & terminal
A full IDE layout — file tree, code editor, live preview, and a real terminal.
The workspace puts everything in one screen: a file tree to navigate the project, a code editor to read or edit any file by hand, a live preview of the running app, and — for framework projects — a real terminal. Vanilla projects render directly in a sandboxed iframe; framework projects boot a dev server inside a WebContainer (a Node.js runtime that runs entirely in your browser), so npm installs and hot reload all happen client-side with no server round-trip.
You're never locked into chat. Open any file, make an edit, and the preview updates. Switch between pages, watch the terminal output, and inspect exactly what the AI generated. The AI and the manual editor operate on the same files, so you can hand work back and forth freely.
- File tree — browse, open, rename, and delete project files; the tree highlights what the AI just touched.
- Code editor — read and edit any file by hand — the preview reflects your changes alongside the AI's.
- WebContainer preview — framework apps run a real dev server in-browser with npm install and hot reload; vanilla apps render in a sandboxed iframe.
- Terminal — watch install and build output, and see runtime logs from the running app.
Visual editing on the live preview
Click an element on the running app and edit it — by hand or with a scoped AI prompt.
You don't have to describe where a change goes when you can just point at it. Turn on visual editing and the preview becomes interactive: click any element to select it, and a floating toolbar appears with quick actions. Double-click text to edit it inline, right on the page. For anything more involved, type an instruction and the builder sends a scoped, element-aware prompt to the AI so it edits exactly the part you picked rather than guessing.
This closes the loop between seeing and changing: select the headline, retype it; select a button, ask for a different style; select a section, ask to rework its layout. The selection travels with the prompt, so the AI always knows the target.
- Click to select — pick any element on the live preview; a floating toolbar surfaces quick actions for it.
- Inline text editing — double-click text to edit it directly on the page, no code required.
- Scoped AI edits — type an instruction for the selected element and the AI changes just that part.
- See-then-change — the selection is sent with your prompt, so edits land on the exact element you pointed at.
Catching & fixing errors
Runtime errors surface in the preview, and the builder can fix them surgically.
When the running app throws, the builder catches it. A preview error overlay shows what failed and where, and an error-storm detector recognizes when the same error is repeating so you're not buried in noise. From there you can send the error back to the AI for a surgical fix — a targeted patch aimed at the specific failure rather than a full rewrite — or hit "Fix all" to address everything caught in one pass.
Because the fix path is patch-based and error-aware, recovering from a broken state is usually one click, and the builder keeps the rest of your project untouched while it repairs the part that broke.
- Error overlay — runtime errors from the preview surface with their message and location instead of failing silently.
- Storm detection — repeated identical errors are collapsed so a single bug doesn't flood the panel.
- Surgical fix — send an error to the AI for a targeted patch that repairs only the failure.
- Fix all — address every caught error in one pass when several pile up.
On-brand by default: the Context Engine
Your brand tokens and offer facts flow into every generation.
The App Builder is wired into the same Context Engine that powers the rest of Mass. Your brand tokens — colors, fonts, and styling — are injected into the system prompt, so generated pages start on-brand instead of generic. Your offer context (what you sell, to whom, the angle) is available too, so copy and structure reflect your actual business.
You can also point the builder at a specific onboarding context, and switch between contexts mid-session. That means the same builder can produce work for different offers or brands without you re-explaining who you are each time.
- Brand tokens — your palette, fonts, and styling are injected into generation so output is on-brand from the first turn.
- Offer context — what you sell and to whom informs the copy and structure the AI writes.
- Switchable contexts — pick which onboarding context drives a session, and switch contexts without leaving the builder.
One source of truth
The same offer facts that resolve {{variables}} across your funnels feed the App Builder, so a page you generate here stays congruent with the rest of your Mass system.
Studio Mode: funnels & the launch checklist
Build a whole funnel page by page, guided by the same checklist that drives onboarding.
In Studio Mode the App Builder knows it's building a funnel. It infers the funnel type from your files and figures out the full set of pages that funnel prescribes — opt-in, sales page, checkout, upsell, downsell, thank-you, and so on — then tells the AI exactly which pages exist and which are still missing on every turn. Ask it to "make the checkout" and it creates checkout.html with the right purpose, instead of cramming a new step into an existing page.
A checklist panel rides along the right rail — the same launch checklist that powers chat onboarding, so your progress carries between the two surfaces. Clicking a step issues a scoped build prompt to the builder to create that page or feature, and the step auto-completes when the AI finishes. That makes the App Builder the place where the launch checklist's pages actually get built.
- Funnel-aware — infers the funnel type from your files and derives every page the template prescribes.
- Expected-pages guidance — each turn tells the AI which pages are done and which are missing, with the right filename for each.
- Right-rail checklist — the shared launch checklist rides along; clicking a step prompts the builder to build that page or feature.
- Auto-complete — a step marks itself done when the AI finishes the build it kicked off.
Clone from a URL & remix
Start from any live site or any project — mirror it faithfully or rebuild it to a brief.
You don't have to start from a blank file. Clone from URL takes any public web page and brings it into the builder: mirror mode reproduces it with high fidelity — mirroring assets, sanitizing scripts, rewriting URLs — while rebuild mode uses a screenshot and a distilled brief to regenerate it as clean, editable code. A phased progress view (validate → render → mirror → sanitize → save) shows where it is, and it respects robots rules and a daily cap.
Remix works on projects you already have: point it at a source project, change the parameters (offer, audience, brand, copy), and the AI rewrites only the targeted content while preserving the structure and layout that already work. It's the fastest way to turn one winning page into many.
- Mirror a site — reproduce a public page with high fidelity — assets mirrored, scripts sanitized, URLs rewritten.
- Rebuild to a brief — regenerate a page from a screenshot and distilled brief as clean, editable code.
- Remix a project — swap offer, audience, brand, or copy and keep the structure that converts.
- Safe by design — respects robots rules and a daily cap, with a clear phased progress view.
Templates & sessions
Start from a template, save your own, and pick up any past build.
New projects can start from a template — a starter scaffold for the stack you want — and Studio Mode offers funnel-shaped templates that pre-seed the page set. When you build something worth reusing, save it as a template; the community gallery surfaces what other builders have shared so you're rarely starting from zero.
Every build is saved as a session. A sessions sidebar lists your past projects so you can reopen, rename, duplicate, or trash any of them, and a trash with a 30-day recovery window means a mistaken delete is reversible.
- Template picker — start a project from a starter scaffold; Studio Mode adds funnel-shaped templates that seed the page set.
- Save as template — turn a build you like into a reusable starter for next time.
- Community gallery — browse and start from templates other builders have published.
- Sessions & trash — reopen, rename, duplicate, or restore past builds; trash keeps deletes recoverable for 30 days.
Forms & environment variables
Wire up lead capture automatically, and manage secrets for framework apps.
Lead-capture forms are detected automatically. When you publish, a preflight check flags any unconnected form, and a one-click "Auto-connect forms" affordance mints a backing record for each, patches the HTML to point at it, and retries the publish in the same click — so a form you dropped on the page actually collects leads without manual plumbing. You can also connect a form by hand when you want fine control.
For framework projects that need secrets — an API key, a service URL — the environment manager lets you add and manage environment variables for the project, so your app can talk to external services in preview and after deploy.
- Form detection — lead-capture forms are found automatically and checked before publish.
- Auto-connect & retry — one click backs every detected form, patches the markup, and re-runs publish.
- Manual connect — wire a specific form by hand when you want precise control.
- Env manager — add and manage environment variables for framework apps that call external services.
Snapshots, history & undo
Every turn is captured, so you can roll back to any point.
The builder snapshots your file tree per turn. A snapshot timeline lists each state with a label and timestamp, and "Restore" rolls the whole workspace back to that exact point — useful when a turn took the project somewhere you didn't want. Pin the snapshots you care about so they survive the automatic prune that keeps the newest set per project.
Alongside snapshots, you can undo the most recent AI turn, and a turn-changes view summarizes what each turn actually altered, so you always understand what changed before deciding to keep or revert it.
- Per-turn snapshots — the file tree is captured every turn, each labeled and timestamped.
- Restore — roll the whole workspace back to any snapshot in one click.
- Pin — mark important snapshots so they're exempt from the automatic prune.
- Undo & turn changes — undo the last AI turn, and review a summary of what each turn changed.
Publishing & deploying
Ship to platform hosting, your own provider, or GitHub — with SEO and a custom domain.
When a build is ready, publish it. The simplest path is in-platform hosting: Mass serves your project at a short workspace URL with no external account needed. Prefer your own infrastructure? Deploy straight to Vercel, Netlify, or Cloudflare Pages with a personal access token. Either way a preflight catches common blockers (like unconnected forms) before you go live, and SEO fields — title, description, and an OG image — are set at publish time.
You can also push the whole project to GitHub — connect an account, pick or create a repo, and commit — or export it as a download to take it anywhere. After publishing, the builder captures a fresh thumbnail of the live page so your sessions list stays visual.
- Platform hosting — serve at a short workspace URL with no external account required.
- Provider deploy — ship to Vercel, Netlify, or Cloudflare Pages with a personal access token.
- GitHub & export — push to a GitHub repo (connect, pick/create, commit) or download the project to take it anywhere.
- SEO & preflight — set title, description, and OG image at publish; a preflight catches blockers before go-live.
Custom domains
Platform-hosted builds can sit behind your own domain, so the page your audience visits is fully branded — no platform URL in sight.
Credits & rate limits
Generation is credit-aware and rate-limited, so costs and pace stay predictable.
Every AI turn consumes credits, and a cost meter keeps the running spend visible as you build. The builder is rate-limited too, so a burst of rapid requests is paced rather than failing outright — if you're going faster than the AI can keep up, it tells you to wait a moment instead of erroring.
- Cost meter — see the credits a session is consuming as you go.
- Rate limiting — rapid-fire requests are paced with a clear message rather than hard failures.