July 16, 2026 · Handbook

Manual: the build chat

Every build owns a conversation, and that conversation is the entire iteration interface — there's no separate editor to learn. A few habits make it work dramatically better.

Phrasing changes

Concrete beats abstract, and outcome beats implementation. "Make the header darker and put the schedule on its own page" lands better than "improve the design", and "visitors should be able to book without creating an account" lands better than instructions about session cookies. You can stack several requests in one message — they become one new version together.

Instead of…Say…
"Improve it""The hero text is hard to read on the photo — give it contrast"
"Fix the game feel""The jump floats too long; make it snappier"
"Add auth somehow""Players need accounts so scores persist"

What the version cards do

Each completed round produces a version card: live Preview, the Code tab (browse every file), Download, and the actions menu — publish, build native installers, ship to a store, save as a template, deploy. Old cards stay fully functional; comparing two versions is just opening both previews. The card also carries the build's verification record.

Habits that pay off

  • One theme per message. "Everything about the schedule page" in one message, "the color direction" in the next — versions stay reviewable.
  • React to the preview, not your memory of it. Open it, click around, then write. Most "the AI got it wrong" moments are actually "I hadn't looked yet".
  • Ask for what's missing, not how to build it. The builder owns the how; you own the what. The division is what makes plain language sufficient.
  • Use follow-up suggestions. After each completed build, the chat proposes next improvements — they're drawn from the build itself and often notice what you'd miss.
Nothing here is destructive. Every message that changes the build makes a NEW version beside the old one — the safety story is in Iterating without fear.
← All posts