Working with the builder
How a turn works, Build versus Discuss, questions and approval cards, queuing messages, attachments and dictation.
Last updated October 13, 2026
On this page
The builder is a conversation. Every message you send is a turn: the builder reads the current state of your app, says in a sentence or two what it is about to do, does it, and closes with a plain summary of what changed. This page covers the controls around that conversation.
Build and Discuss
The switch next to the message box has two modes:
- Build changes your app. This is the default.
- Discuss talks it through without touching anything. Use it to plan a feature, ask what the builder would recommend, or understand how something works before you commit to it.
Your choice is remembered per browser, so check the label before a message you mean as an instruction.
Questions, keys and approvals
Some turns end on a card instead of a summary. A card is the builder pausing because it needs something only you can give:
| Card | What it needs | What to do |
|---|---|---|
| Question | A decision that changes what gets built, such as who can see what | Tap an option or type an answer |
| Secret | A key for an outside service, such as a payment provider | Paste the value. It is stored encrypted and never shown again. See Secrets |
| Setup | Several values from one provider, or an account you already hold | Fill in the card, or tell the builder to go without it |
| Approval | Permission to clear rows from a table | Approve or decline. Nothing is deleted until you approve |
The builder asks for keys and setup at the start of a job, so answer the card and the next message resumes exactly where it stopped. Anything the builder wrote before asking still builds, so the preview keeps moving while the card waits.
Queuing messages
You can keep typing while a build runs. Messages wait in a queue under the conversation and go out one at a time, each with its own attachments. Pause holds the queue, Clear empties it, and you can drag items to reorder them. The queue is saved with the app, so it survives a refresh or a switch to another device.
Attachments and dictation
Attach a file with the paperclip: a screenshot of something you want copied, a sketch, a spreadsheet of starter data, a PDF of your brand guidelines. The builder reads images and documents. Press the microphone to dictate a message instead of typing it.
Long jobs
A large build is several rounds of work. When one round is used up the builder says it is carrying on and continues by itself, with the router and shared layout written first so a part-finished build is never a broken one. You never need to say "continue".
Checking that it runs
Compiling is not the same as working, so after each build the platform opens the app in a browser of its own, signed in as you, and hands the builder anything the pages threw. A page that compiles but fails to render is usually fixed before you see it. The builder can run the same check itself on any page, and your own browser reports what the live preview does, a request that failed, a page that threw an error, with your next message, so a broken button is usually fixed without you having to describe it.
One kind of error is left alone on purpose: an embedded map, video or social post can complain inside the preview, which is sandboxed for your safety. The published app is not sandboxed, so the embed works there.
Credits
Each turn uses credits for the work it does. The Usage page shows a line per app. See Hosting, credits and usage.
Tips that make a difference
- One job per message. "Add a teachers page" then "Let members book from it" beats both at once.
- Say what you can see, not what you guess is wrong: "the Book button on the schedule does nothing".
- Tell it what to leave alone: "keep the pricing page exactly as it is". It remembers.
- Use Discuss before a big change so you agree on the plan first.