Skip to main content

​
How building works

In Build mode you describe outcomes. The AI usually proposes a plan before major work. After you approve, GenieForge assembles the change into your app blueprint and the selected project’s runtime. You review whether the result matches the business you described. That is the difference from unconstrained code generation: GenieForge keeps an operable product you can Preview, permission, and evolve, not a disposable pile of files.

​
The build cycle

  1. Describe the outcome (who uses it, what must happen, constraints).
  2. Review the plan for roles, journeys, and rules. When the plan adds or changes screens, the card includes simple page sketches (gray-box wireframes) so you can picture the layout. Highlighted blocks show what is new, updated, moved, or removed. Edit or reject before heavy work.
  3. Let GenieForge implement against the selected project so you can Preview real behavior.
  4. Test: Preview as each role (use Draft while iterating, Published before you ship). Click the critical path. Check Executions if a job ran.
  5. Tighten access under App Blueprint → Access when permissions look wrong.
  6. Publish from the builder banner when the draft is ready for customers (or open sidebar Publish for history and rollback).
Inside a strong Build turn, GenieForge reads what already exists, reuses it when possible, fills the gap, and remembers lasting preferences you put in Build Rules or App Documentation. You do not pick the internal recipe labels.

​
Ask for outcomes, not rebuilds

Prefer “add a weekday digest for open high-priority items” over “rewrite the whole frontend.” Prefer extending what already works over starting a parallel stack when the plan proposes a duplicate path. When work is long-running (imports, transcription, bulk sync), it should not hang chat. Confirm long jobs under project Executions.

​
Example: one outcome end to end

Suppose you already take requests and need assignment:
  1. Prompt: “Staff can assign open requests. Staff get notified. Requesters only see their own rows.”
  2. Plan should make the role journeys and ownership rules obvious. Approve when that looks right.
  3. Test: Preview as requester (cannot assign others’ rows) and as staff (can assign, receives notice).
  4. Mark done when Preview and Access agree; then continue with the next small ask.
If the first result is incomplete, refine with a named follow-up (“only managers may reassign”) instead of restarting from a blank prompt.

​
Build Rules

Build Rules (App Blueprint → Build Rules) are lasting conventions that apply across every Build conversation. Examples:
  • Always key ownership to user ids, not email addresses.
  • Never expose financial fields to the client role.
  • Put work that may take more than a few seconds in the background so chat stays responsive.
  • Preserve the existing navigation style unless I ask to change it.
  • Ask before deleting a table.
When a prompt conflicts with a Build Rule, treat the rule as the default preference and call out the conflict in the plan so you can choose.

​
What can go wrong