Reviewed by Product Specialist at thinQit. Updated 29 October 2026.
An AI website launch should be checked in a fixed order before you publish: compare the build with the approved plan, review every screen size in the preview, confirm the domain and HTTPS, and test each form and key action. thinQit, the Dutch AI workspace behind the Codex website builder, designs its publish step around exactly this sequence.
Why does an AI-built website need a launch check?
An AI-built website needs a launch check because the builder makes structural decisions on your behalf, and you only own those decisions once you have reviewed them. A launch check turns "it looks fine" into a short list of things you confirmed with your own eyes.
With a traditional project, a developer reports what was built. With an AI website builder such as Codex, the result appears in a live preview next to the chat, so the review is quicker but also easier to skip. The check below keeps that speed while making sure nothing reaches visitors unseen. It does not replace a legal or accessibility review where your sector requires one, and it assumes the plan was settled before the build began. If that was not the case, start with the guide to the minimum context an AI website builder needs to start.
How do you check the build against the approved plan?
Compare the finished site to the plan you approved, page by page. The plan is the contract: it lists the pages or screens, the style and the colours, and the builder should not have drifted from it without you asking.
In Codex, Cody asks what you are making, who it is for and which pages or screens you need, then writes a plan that you can change as often as you like. The build starts when you say it looks right. That makes the approved plan a reliable reference at launch time. Work through it with these questions:
- Is every page or screen in the plan present, and is anything present that you did not ask for?
- Do the logo and colours match what you supplied, or the palette Codex picked for you?
- Does each page carry the information a visitor needs before the next action?
- For a web app, does each screen show the data you planned?
Any gap you find here is cheaper to fix now than after publishing. Ask for the change in plain words and the preview updates. The article on controlling an AI website builder after the first build describes that review loop in more detail.
How do you review the live preview properly?
Review the preview on all three screen sizes and by actually using the site, not just scrolling it. The preview shows what a visitor will see, which is more reliable than reading a description of what was built.
Codex lets you switch between computer, tablet and phone views, or open the site in a new tab. Builds run in the background, so you can close the page and come back later, and the preview link stays the same after every change. That stable link is useful: you can send it to a colleague for a second opinion without waiting for a publish.
Phone view first
Open the phone view before the others. Narrow screens expose the problems that wide screens hide: long headings that wrap awkwardly, buttons placed too close together and images that crowd the text. If the phone view reads cleanly, the larger views usually follow.
Computer and tablet views
On computer and tablet, check the navigation, the order of sections and the spacing between them. Confirm the main action, such as contacting you or placing an order, is visible without hunting for it.
What should you confirm about the domain and HTTPS?
Confirm which address the site will be published on and that it is secure. Codex publishes either on a free thinQit.site subdomain that works right away with no DNS work, or on a domain you own, with HTTPS set up for you.
The choice changes what you have to verify. On a thinQit.site address there is nothing to configure, so the check is only that the name is the one you want; Codex lets you check whether a name is free before you publish. On your own domain, Codex shows the DNS records to add at your domain provider and verifies them for you. Do not announce the address until that verification has succeeded, and open the final address once to confirm it loads over HTTPS.
| Publish option | What you do | What to confirm |
|---|---|---|
| Free thinQit.site subdomain | Choose a name and publish | The name is free and is the one you want |
| Domain you own | Add the DNS records Codex shows | Codex verified the records and the site loads over HTTPS |
How do you test forms and key actions?
Test every form and every 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.
Make a short list from the plan: the contact form, an ordering step, a sign-in, a download. For a web app backed by a database, such as an ordering app, a client portal or a dashboard, run through one realistic task from start to finish and check that the data you entered appears where it should. Try the app in the live preview first, then repeat the same task once on the live address. If something fails, ask for the fix in plain words and repeat the test; a small tweak, one page or a full rebuild are all possible.
What does a build cost, and what happens if it fails?
Codex plans include monthly credits for building, your balance is checked before a build starts, and a build that fails is not charged. That matters at launch because fixes after review consume credits like any other change.
The Sites Launch plan has 150 credits a month and starts from €20 a month, and the App Launch plan has 450 credits a month and starts from €50 a month. Current plans are on the thinQit pricing page. Group your review notes into one clear request instead of many tiny ones, so each rebuild addresses several findings at once. Security-minded teams can also read how thinQit handles data on the security page before connecting a domain.
When should you delay the launch?
Delay the launch 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 on the live address. Publishing is quick, so there is no reason to publish early.
The same applies if product decisions are still open. A builder will produce a polished interpretation of an unresolved question, so settle the audience, the pages and the main action first. For a worked example of the whole path from discovery to iteration, see inside an AI web app build.
Curious what it costs?
See the pricing and pick what fits you.
Frequently asked questions
Can I publish first and review later?
You can, but it is better not to. Review in the live preview first, since the preview link stays the same after every change and shows exactly what visitors will see.
Do I need my own domain to launch?
No. Codex can publish on a free thinQit.site subdomain that works right away. If you prefer your own address, Codex shows the DNS records to add, verifies them and sets up HTTPS.
What if the launch check finds a problem?
Describe the fix in plain words and the preview updates. A change can be a small tweak, one page or a full rebuild, and you repeat the relevant check afterwards.
Will a failed build use my credits?
No. A build that fails is not charged, and your balance is checked before a build starts.
Does the same check apply to a web app?
Yes, with extra attention to the data. Run one realistic task through each screen, such as placing an order, and confirm the database shows the result.
Sophia is thinQit's AI SEO & GEO specialist. She runs continuous technical audits, maps search and answer-engine intent, and tunes content so it ranks on Google and gets cited by ChatGPT, Perplexity, Gemini and AI Overviews.
