How it works
How a build runs
Between your sentence and your preview there are seven steps, and only one of them involves a model writing code. The other six exist to make what it writes safe to run and honest to show you.
Last updated 19 August 2026
What happens after you describe an app?
sup3rapp picks a tested scaffold that fits what you asked for, and the model proposes a list of structured file-edit operations against it. A deterministic executor validates those operations and applies them atomically. The build is then verified — typecheck → tests → production build → smoke test — inside a sandbox isolated to your project. Only then do you see it.
The model is one step in that sequence, and it is the only step that is not deterministic. Everything around it — where the code starts from, how edits are applied, what has to be true before you see the result — is ordinary software that behaves the same way every time.
The pipeline
Seven steps, in order
| Step | What happens | What it guarantees |
|---|---|---|
| You describe the app | Plain language, in a prompt box. No spec to fill in, no schema to draw. | Ambiguity is resolved by assuming a sensible default and letting you correct it by chatting. |
| A scaffold is chosen | The build starts from a real, tested application — not an empty directory. | The model never invents project structure, so the parts that usually rot are already right. |
| The model proposes edits | It returns a list of structured file operations: create, replace, delete, rename. | The model has no filesystem and no network. It cannot act, only propose. |
| The executor applies them | A deterministic executor validates every path and applies the whole list at once. | All of the operations or none of them. A half-applied change cannot exist. |
| Verification runs | typecheck → tests → production build → smoke test, in that order, inside your project’s own sandbox. | The preview is held until the chain passes. You are never handed an unverified build. |
| Failures are repaired | The failing stage returns structured diagnostics, the model repairs, the chain restarts. | The loop is bounded. You see the repair happen rather than an error to debug. |
| The preview opens | A real running application in an isolated sandbox — not a rendering of one. | Each build is an immutable, content-hashed version, so every message is a restore point. |
Why start from a scaffold instead of an empty folder?
Because project structure is where generated applications come apart. The first prompt of any AI app builder looks fine. The trouble starts on the third, when a change needs to touch routing, or auth, or the database layer — parts that were invented in a hurry on the first pass and were never coherent to begin with.
A sup3rapp build starts from an application that already works. Each scaffold ships with routing, auth, a database client, error boundaries, design tokens and a passing test suite, and each one is a real committed codebase with its own tests running on every change. The model modifies working software. That is a much smaller job than inventing an architecture, and a much easier one to verify.
| Scaffold | What it is | Ships with |
|---|---|---|
| marketing site | A landing page, a lightweight content model, and contact forms. | routing, content model, contact forms, design tokens, a passing test suite |
| SaaS starter | Authentication, a Postgres schema, a dashboard shell, and billing wiring. | auth, Postgres schema, dashboard shell, billing wiring, a passing test suite |
| internal tool | CRUD tables, filtering, and role-based access. | CRUD tables, filtering, role-based access, design tokens, a passing test suite |
What is an edit operation, and why does it matter?
An edit operation is a single structured instruction — create this file with this content, replace this text in that file, delete this path, rename this to that. The model returns a list of them. It does not run commands, open sockets or write to disk; it has no way to.
The executor checks every path in the list against an allowlist, then applies the whole list as one unit. If any operation in the list is invalid, none of them are applied. So a project is never left in a state that is half of one change and half of another — which is the state that makes generated code impossible to reason about, and impossible to roll back cleanly.
What has to be true before a preview appears?
All four stages of the verification chain have to pass: the code typechecks, the tests pass, it builds the way it would build on the day you ship it, and the built application actually starts and serves a page. On our marketing-site scaffold, in a network-less sandbox, that chain takes 37.4s.
If a stage fails, you do not get an error message. The diagnostics go back to the model, the repair is applied, and the chain runs again from the top. What you see is the repair happening — and then a working app.
Where does the generated app run?
In a sandbox isolated to your project — during verification, during the preview, and after you publish. Generated code is untrusted code. It never executes on shared infrastructure, and it never runs alongside another project.
The preview is that sandbox, served to you. It is a real running application, not a simulation of one, which is why what you click through behaves the same way the built app behaves.
What happens to the version I had before?
It still exists, byte for byte. Every build is immutable and content-hashed, and asking for a change produces a new version rather than editing the one you have. Every message in the conversation is a restore point.
Rolling back moves a pointer to an earlier version. It is not a rebuild, so there is nothing to recompute, nothing to half-apply, and nothing that can fail partway.
Watch it run on something you actually need
sup3rapp is in private beta. Access is by request; there is no self-serve signup yet. Tell us what you want to build and we will match you to a batch as places open.