Using the App Builder

Open Workbench → Apps and create or open an app to land in the builder: a chat panel on one side, a live preview on the other. Everything you build lives in a file tree (HTML/CSS/JS, or a small framework project) that the chat agent edits on your behalf, and that you can also edit by hand.

Three chat modes change what a message does:

Type what you want and send. The builder streams the agent's reasoning and the tool calls it makes (editing a file, reading another) live into the chat, then applies the resulting file edits to your project — a toast confirms how many files changed. The preview updates without a full reload.

• Stop requests cancellation and waits for the run to actually end — it does not assume the cancel worked before the server confirms it.
• A run that goes quiet for about two minutes is treated as stalled and reported as failed, rather than left spinning forever.
• If a deploy fails to build, or the live preview fails to compile, the builder automatically sends the error back to the agent to fix — up to two attempts, each a normal metered run. It will not loop forever on your BICS.

Every builder chat turn that touches files is billed in BICS, same as any agent run. While you are building (the app is unpublished), this is charged to your organisation's BICS pool — not a visitor's wallet, which only applies after you publish (see Billing and the wallet).

The builder shows one of two previews:

A development app's preview runs on its own address, open only to your workspace — it mints a short-lived preview session automatically rather than exposing your login.

The model picker lists active models capable of reasoning — not one fixed provider. Pick a stronger model for a hard refactor, or a cheaper one for a small tweak; only models tagged for vision let you attach images to a chat message.

The Themes panel edits your project's CSS color variables (the :root block in your stylesheet) as swatches — a fast way to retheme without asking the chat agent to rewrite CSS by hand. It does not touch layout, spacing, or fonts; those are still a chat edit.

Bring images, fonts, video, audio, and PDFs into your project four ways: drag-and-drop upload, an AI-generated image, importing from a URL, or attaching a file in chat. Binary files are stored separately from your code (your file tree stays text-only) and referenced by a manifest the builder maintains for you.

Per-file limit: 25MB.

App config (botspot.app.json) is the one part of your project the chat agent does not own — it's declared by you, and the builder reads it directly. It holds your app's display name, the agent roles your pages can call (see Backend, below), what data collections it may read, and your build settings. This must be filled in before you can deploy.

The SEO pane writes real tags and files into your project — nothing here is a preview-only mock:

• Search result — title, description, canonical URL, with a Google-style preview.
• Shared links — Open Graph and Twitter card previews for social shares.
• Being found — robots.txt and sitemap.xml.
• Rich results — structured data (JSON-LD) by content type.
• Everything else — theme color, icons, and the raw output if you want to hand-edit it.
• A built-in checklist scores what's set and what's missing.

It reads back its own previous output, so re-opening the pane never clobbers tags the chat agent or you wrote by hand elsewhere in the page head.

An App's backend is one of your own agents. In App config, declare a role (a name your page calls, like "assistant"); in the builder's Backend screen, bind that role to a real agent. Your page then calls it with botspot.run(role, input) — this binding is live, not a mock wiring diagram.

Attach one of your organisation's existing connected data sources to the app. This only records a pointer — no data is copied or moved, and no credential ever reaches the browser. Detaching just removes the pointer; nothing is deleted.

In App config's auth settings, choose how the app treats sign-in: no auth at all, sign-in through your MyCrew account (BotSpot holds the users), or your own user table. This is a real decision written into your app's config — pick it based on who you expect to use the app, since changing it later can mean existing users have to sign in again.

Three ways to bring code in, from the ⋯ menu's Import code option:

Anything imported is scanned for server-only code and secrets (API routes, server framework hooks, .env values) before it lands — you'll be asked to convert it to a botspot.run call or point it at your own backend. Secrets are always stripped.

Deploy builds your current files and puts them on your app's address. It's blocked until App config is filled in, and warns (without blocking) if an asset reference would 404. Publish only becomes available after a build has deployed successfully, and is what actually makes the app reachable by visitors — see who pays once it's published.

A .botspot.app address carries a small "Request something similar" prompt by default. Remove it as a one-time purchase from the deploy flow (priced live, charged once to your organisation) — connecting a custom domain removes it for free.

Every save of your project — a chat edit or a manual save — keeps a snapshot. Open the ⋯ menu above the preview and choose Version history to see every save, newest first, and roll back to any of them.

Restoring is never a dead end: a restore takes its own snapshot too, so picking the wrong version is always undoable from the same list. It restores your files — it does not change your agent binding, database attachment, or auth setting, since those live outside the file tree.