Reviewed by Product Specialist at thinQit. Updated 10 November 2026.
To plan a web app for an AI web app builder, list three things before you describe it: the records the app must keep, the roles that use it, and the screens that carry the main task. thinQit's Codex builds database-backed apps from a conversation, and a clear data plan is what makes the first preview match your intent.
What does an AI web app builder need from you?
An AI web app builder needs to know what the app is for, who uses it and what information it keeps. Codex is built around this: you tell Cody, the thinQit AI developer, what the business does and who the app is for, and Cody asks a few focused questions and writes a plan for you to approve. The builder cannot invent your business rules, so anything you leave out becomes a guess.
Codex describes its web apps as interactive apps backed by a real database, such as an ordering app, a client portal or a dashboard. Each example stores something: orders, client documents, figures. That stored information is what your plan must define. You can add a logo, photos or a PDF to the conversation, which is a good place to attach an existing price list or form you want the app to replace.
How do you list the records your app keeps?
A record is one stored item, such as an order or a client request, and a record type is the template for it. Start by naming each record type, then list its fields and its statuses. This step is the core of the plan because screens are only views of records. A missing field found late changes several screens at once.
Take a small ordering app as an example. The record types might be customer, product and order. An order holds a customer, one or more products with quantities, and a status such as new, confirmed or delivered. Writing that down takes ten minutes and answers most of the questions the builder would otherwise ask.
| Record type | Fields to list | Question to settle |
|---|---|---|
| Customer | Name, contact details | Do customers log in or does staff enter them? |
| Product | Name, description, price | Who edits products? |
| Order | Customer, items, status | Which statuses exist, and who changes them? |
Keep each field to one fact. A field called "details" that holds a name, an address and a note is three fields in disguise, and it makes search and reporting harder later.
How do you define roles and what each one sees?
A role is a type of user with its own permissions and its own view. List every role that logs in, and write one sentence per role about what it may see and change. Roles matter because an app, unlike a website, shows known users their own data. Without roles, every user sees everything, and fixing that afterwards means reworking screens.
- The customer sees only their own orders and can place a new one.
- The staff member sees all orders and can change their status.
- The owner sees the dashboard summary and can edit products.
Three roles are enough to start. You can add more through the chat once the first version works. The boundary to watch is any role that needs data from another person's account: decide explicitly whether that is allowed, because the builder will not assume it.
Which screens should the first version include?
The first version should include only the screens that carry the main workflow, usually three to five. Each screen should map to a record type and a role: a list, a detail view and a form are the common shapes. Codex plans the screens and the data in the chat, so naming them yourself shortens the conversation and makes the plan easier to approve.
For the ordering app, the first screens could be a product list, an order form, an order status page for the customer and an order queue for staff. A reporting view can wait. Starting small matches how Codex works: you ask for changes in plain words, and the preview updates, so a missing screen is a short request later and not a restart.
How does the plan become a live app in Codex?
Codex follows three steps: describe, preview and publish. After you approve the plan, Codex builds the first version and shows it live next to the chat. You can switch between computer, tablet and phone views, and builds run in the background, so you can close the page and come back later. When it looks right, you publish.
Publishing happens on a free thinQit.site subdomain that works right away, or on a domain you own. For your own domain, Codex shows the DNS records to add, verifies them and sets up HTTPS. The preview link stays the same after every change, so you can share one address with colleagues while you iterate. For a fuller walk through the stages, read inside an AI web app build.
What does it cost to build a web app with Codex?
According to the Codex page, web apps start from €50 a month on the App Launch plan, which includes 450 thinQs a month, while websites start from €20 a month with 150 thinQs. Your balance is checked before a build starts, and a build that fails is not charged. Plan comparisons are on the pricing page.
A good data plan also protects your allowance. When the builder starts with clear records, roles and screens, you spend thinQs on refinements, not on rebuilding a structure you did not define.
Where do existing code and recurring work fit?
Codex builds new websites and web apps. When you already own a codebase and need a change in it, Cody maps your repository, plans the steps, writes the code, runs your tests and opens a pull request for review. After launch, recurring work such as SEO, social media, design and reporting belongs to the AI teammates. Planning who handles what keeps the app maintained after day one.
Curious what it costs?
See the pricing and pick what fits you.
Frequently asked questions
How many record types should a first version have?
Start with the two to four types the main workflow cannot work without. An ordering app needs customers, products and orders. Additional types can be requested through the chat after the first preview.
Do I have to design the database myself?
No. You describe the records in plain words, and Codex builds the app on a real database. Your job is to state what must be kept and who may see it.
Can I attach existing documents to help the plan?
Yes. You can add a logo, photos or a PDF when you describe the business, so Cody can use them while writing the plan.
What if I forget a field?
Ask for it in the chat. Codex updates the preview after each request, from a small tweak to a full rebuild. A field found early costs less than one found after many screens exist.
Can customers and staff use the same app?
Yes, if you define the roles. Write what each role sees and changes, and the plan will reflect it before the build starts.
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.
