It writes the code, then repairs it

What happens after you press send

The request is sized first. That size decides the model, the depth of the work, and the credits.

A large structural change asks you to confirm before anything starts. Smaller changes go straight through.

• Large structural change (T1) — 6 credits, confirmed by you first
• Ordinary feature work (T2) — 2.75 credits
• Copy tweaks and small edits (T3) — 0.5 credits

Five repair attempts, then it stops

If a check fails, the builder repairs its own work. It gets three attempts under the original settings.

If those run out it moves to a stronger model and gets two more. After the fifth it stops instead of looping.

When it stops you get a plain-language report: what it tried, how many times, and what to do next. Half the credits come back automatically. If it stopped because our side could not reach the model, all of them do.

What gets checked before you see it

A page that renders is not the same as an app that works. A save button that silently fails looks perfectly fine.

• The code compiles with no errors
• Every data table has access rules turned on and at least one rule written
• An app with no sign-in is not locked to signed-in visitors only
• Names, phone numbers and similar details are not readable by anyone
• No secret key is sitting inside the source
• The output is in the language you asked for, with matching currency

It can only write in three places

The builder writes to the screens folder, the public files folder, and the data design folder. Nothing else changes, however the request is phrased.

Generated files are refused too — they get rewritten on the next build, so editing them only looks like it worked.

What we measured

On 22 August 2026 we built seven businesses end to end from a real account. All seven finished.

Builds took 221 to 616 seconds, averaging 370. Every one had a single page heading, no broken images, and no sideways scroll on a phone.