The flagship claim
The verification chain
Four stages run on every build, in the same order, in a sandbox of your project’s own. The preview is held until they pass. This page is what each stage proves, what it cannot prove, and what happens when one fails.
Last updated 19 August 2026
What is a verification chain?
A verification chain is a fixed sequence of checks that a generated build must pass before anyone sees it. In sup3rapp it is four stages — typecheck → tests → production build → smoke test — run in that order inside an isolated sandbox. Any failure stops the chain, returns structured diagnostics, and triggers a repair rather than an error message.
The order is not cosmetic. Each stage is cheaper than the one after it and produces better diagnostics, so a build that is going to fail fails early, and the model gets the most precise description of the problem that is available.
> a booking site for my dental practice with patient intake forms reading the marketing-site scaffold planning the schema — patients, appointments, intake responses adding the bookings table wiring the patient intake form applying the file operations atomically running verification typecheck ... failed app/book/actions.ts:41 TS2345: Argument of type 'string | null' is not assignable to parameter of type 'string'. — patient.phone is nullable repairing — narrowing patient.phone before use re-running verification from the top typecheck ... passed in 4.2s tests ... passed in 4.3s production build ... passed in 24.0s smoke test ... passed in 3.9s verified in 37.4s Measured on our marketing-site scaffold, in a network-less sandbox.
Stage by stage
What each stage proves, and what it does not
| Stage | Measured | What it proves | What it will not catch |
|---|---|---|---|
| typecheck | 4.2s | The code is internally consistent: every call matches its signature, every field exists. | Anything that is well-typed and wrong. |
| tests | 4.3s | The behaviour the scaffold already had still holds after the change. | Behaviour nobody has written a test for — including, usually, the feature just added. |
| production build | 24.0s | It compiles under production settings, the way it would on the day you ship it. | Anything that only shows up under real traffic or real data. |
| smoke test | 3.9s | The built application starts and serves a page. | Whether the page it served is the page you wanted. |
typecheck
The code is internally consistent: every call matches its signature, every field exists.
The single most common failure in generated code — a value that might be null used as if it never is.
tests
The behaviour the scaffold already had still holds after the change.
A change that quietly breaks auth, routing or data access somewhere the model was not looking.
production build
It compiles under production settings, the way it would on the day you ship it.
Code that works in development and fails when it is bundled, minified or rendered ahead of time.
smoke test
The built application starts and serves a page.
An app that compiles perfectly and dies on boot — a bad import, a missing environment value.
What happens when a stage fails?
The failing stage produces structured diagnostics — a file, a line, an error code, a message — and those go back to the model as the input to a repair. The repair is applied as another list of edit operations, validated and applied atomically like any other, and then the chain restarts from the first stage.
It restarts from the top rather than resuming, because a repair is a change to the code like any other, and a change that fixes a typecheck error can break a test. There is no version of this where a stage is skipped because it passed a moment ago.
The loop is bounded. After a fixed number of attempts, the failure surfaces to you instead of looping forever — with what failed and what was tried, not a shrug. Every attempt is logged, because the rate at which repairs succeed per scaffold is the number that tells us whether the product is working.
Is the preview verified too, or only the published app?
The preview is the verified build. There is no faster, looser path for previews and no unverified draft mode — the preview is the same artifact, running in the same isolated sandbox, that publishing later promotes. What you click through is what you would ship.
This is the part competitors are quietest about, and it is the whole reason the second and third prompts feel different here. A preview that was never verified is a demo of a build, not the build.
What does a passing chain not prove?
That the app is the one you meant. Verification proves the code is consistent, that the existing tests still pass, that it builds under production settings and that it starts. It cannot prove that your booking rules are right, that your pricing logic matches your business, or that the wording on the page is what you would have written.
It is also not a security audit, not a performance test, and not a substitute for reading what was built before you put real customer data in it. A verified build is a floor, not a ceiling: it is the guarantee that you are looking at working software, so that the only thing left to judge is whether it is the right software.
Anyone claiming more than that about generated code is selling you the demo.
Put the chain to work on your idea
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.