What Happens After an AI Web App Preview Is Approved?

Reviewed by Product Specialist at thinQit. Updated 13 November 2026.

Approving a preview with an AI web app builder records your decision that the build matches the plan; it does not by itself put the app in front of visitors. The next step is a deliberate publish, followed by checks on the live address, and the app stays editable afterwards.

This article explains what approval means, what you should do between approval and publishing, and how changes work once the app is live. It draws on how Codex, thinQit's website and app builder, handles previews, publishing and later changes.

What does approving a preview actually mean?

Approval is a human decision, made with evidence in front of you, that the build is acceptable against the plan you agreed. It is the approval gate described in Inside an AI Web App Build: Discovery to Iteration: every change that matters passes a person before it moves on.

The boundary matters. Approval says the screens, data and behaviour match what was planned. It does not say the domain is connected, the forms deliver messages or the live address loads over HTTPS. Those are separate checks that come after approval.

What should you do between approval and publishing?

Use the gap for a last pass on the things a preview cannot prove. The preview link stays the same after every change, so you can keep using it while you prepare.

1. Compare the build one more time with the approved plan: every planned screen is present and nothing unrequested has appeared.
2. Open the phone view first, then tablet and computer, and look for wrapped headings, crowded buttons and images that push text aside.
3. Run one realistic task through the app, for example placing an order or submitting a request, and confirm the data appears where it should.
4. Decide the address: a free thinQit.site subdomain or a domain you own.
5. Group any remaining notes into one clear request, so a single rebuild addresses several findings.

The full order of checks is in What to Check Before an AI-Built Website Goes Live.

How does publishing work after approval?

Publishing is a separate step in which you choose the address and the app goes live there. Codex publishes either on a free thinQit.site subdomain, which works right away with no DNS work, or on a domain you own, with HTTPS set up for you.

On a thinQit.site address the only check is that the name is free and is the one you want; Codex lets you check availability before you publish. On your own domain, Codex shows the DNS records to add at your domain provider and verifies them. Do not announce the address until that verification has succeeded.

What should you test on the live address?

Test every form and main action on the published address, because that is the version visitors use. A form that looks correct in the preview still has to be submitted once to prove the message reaches you.

• Open the final address once and confirm it loads over HTTPS.
• Submit each form and confirm the message arrives.
• Repeat the realistic task from the preview on the live address and check the result in the data.
• Check the phone view again on the real address.

If something fails, describe the fix in plain words. A change can be a small tweak, one page or a full rebuild, and you repeat the relevant check afterwards.

What happens when you want a change after launch?

A published app is not frozen: the next change follows the same loop of instruction, build, evidence, approval and live. Because the project keeps its context, the tenth improvement starts from the current state instead of a memory of the kickoff.

Record decisions made along the way in the project's shared context, so later instructions do not contradict them. The guide on controlling an AI website builder after the first build describes this loop, and updating AI documentation after a requirement changes explains how to keep the record current.

Does a failed build cost anything?

A build that fails is not charged, and your balance is checked before a build starts. Fixes after approval consume thinQs like any other change, which is why grouping notes into one request is efficient. Current plans are on the pricing page.

When should you hold off on publishing?

Hold off when the approved plan and the build still disagree, when the phone view is not clean, or when a key form has not been tested. Publishing is quick, so nothing is gained by publishing early. A cautious approach is to start with a small group of pilot users, as in the walkthrough linked above, and widen access once the app answers the questions it was built for.

Frequently asked questions