The Site Builder

The sections library gives a coding agent every building block of a marketing site, already on brand. The site builder assembles them. You describe the company in a sentence or two; braaand plans the pages and the sections on each, writes the copy into every slot and places the pictures — from your own library first, then stock, then generation — and shows the whole site as real pages on a canvas. You reorder, swap, regenerate a section with a direction, type over anything. Then you export the pages into the same project the sections and the style guide already live in.

It follows the shape of tools like Relume: three steps, each costing only what it shows. The sitemap is the plan and spends nothing. The wireframe writes the copy, in neutral greys, seconds per page. The design places the pictures and shows the pages in your brand.

Three steps

Sitemap. Open Sites (in the brand's "…" menu) and press New site. The site opens at once, untitled, with one empty Home page and the Site panel floating on the left: describe the company in a sentence or two, choose how many pages (one, 2–5, 5–8 or 8–12) and the language, say where the pictures should come from (Pictures from: your library, stock, AI generation, in any combination — the brand's own image policy until you tap a chip, then this site's own choice), or paste a website's address to plan the same pages its navigation carries, then press Generate sitemap. One reasoning pass answers with pages — home first, then whatever the description calls for — each an ordered list of sections from the library, with a one-line description per section: what it should say on this page. You watch it being planned: the pass streams, and each page frame and each section card deals onto the board the moment the model writes it, the descriptions growing word by word, so the wait is the site appearing rather than a spinner. The picks are constrained to the real library, every page starts with a navbar and ends with a footer, the whole site shares one variant of each, and surfaces alternate down the page so nothing reads as a wireframe. You never have to press it: the tree behind the panel takes sections by hand, and the wand in the topbar brings the panel back whenever you want to plan again (which replaces the pages, so it asks first).

The Sitemap view shows the site as a tree on the same zoomable board as the pages: the home page on top, every other page beneath it, each page a card of its sections. Drag a section to reorder it, or onto another page to move it. Click one to swap its variant, edit its description or change its surface in the rail, and + Section adds one from the library. The round + between two pages adds a page right there and opens it so you can name it; a new page borrows the site's navbar and footer. Drag a page by its title to move it along the row (the home page stays on top), or hover the title for the arrows and delete. The editor keeps the view you are on in the address, so a reload, or a link you share, opens the same view.

Wireframe. Opening the Wireframe view writes the copy — every section nothing has written yet, a freshly planned sitemap or a block you just added, gets its words, and nothing else: no picture is fetched, so a page is done in seconds. You watch it happen: the sections slide in top to bottom, each section's text types itself out as its copy lands, the surfaces sweep in behind the words, and the pages celebrate with confetti when the last one is done. The pages render in neutral greys, one typeface, flat corners, no shadows, every picture a grey placeholder box (a logo slot shows the wordmark), which is the same style guide resolved from a colourless deposit with your brand's own sizes kept — the type scale, the section spacing and the containers are what you are judging — so the structure and the copy can be read without the look arguing for itself. The bands still band: a muted, inverted or accent surface resolves against the neutral palette too. Everything you can do on the Design view you can do here.

Design. Opening the Design view places the pictures for every section that has copy and no picture pass yet, and shows the pages in the brand — the real colours, the real faces, the real corners. Each section's picture briefs were written with its copy and stored, so this step never rewrites a word; a section whose copy came from a person or an agent gets one small briefing call for its picture slots. The pictures come from wherever the Site panel's Pictures from says (else the brand's image policy). The exported pages are always the branded ones.

The basics are set where you can see them, and they cascade. Click a headline on any page and the rail opens the brand's style guide for that tag — Every Heading 1: its size on the type scale (or an exact size), weight, case, line height, letter spacing, colour, margins — the same controls as the Design System page, writing the same field. Change the size and every h1 on every page moves in the same frame, in the Wireframe view as well as the Design view, and the design system itself has changed: an exported page, a synced project, the style-guide export all carry it. Click a section, or a page, and the rail's Layout block holds the structure: the gutter at the page's left and right, the padding above and below each section, the container widths — brand-wide too. A spacing step edited there is shared with the brand's ads, and the rail says so once before the first such change. Click the brand's mark in a navbar or footer and the rail offers the ad editor's own logo controls: which form of the mark (horizontal, vertical, emblem, whatever the logo system carries), its treatment (following the section's surface, or pinned on-dark, on-light or full colour), a specific asset, a tint for a recolorable mark — resolved through the same resolver an ad uses, so the site's navbar and the brand's ads can never disagree about which file "the horizontal mark on dark" is. A pick is kept on the slot, so changing the section's surface re-picks the same way (a vertical mark stays vertical; a pinned treatment stays pinned).

The block picker shows you the blocks. Adding or changing a block opens the library as a grid of real previews — each one the section itself, rendered in your brand's own style guide, so you pick by looking rather than by guessing what "Split" means next to "Centered". Families run down the left with a count each, and the search box ranks across a block's name, its family and what it does, so questions finds the FAQ blocks without the word FAQ. Arrow keys move, Enter picks. When you are CHANGING a block, the alternatives lead: the rest of that block's own family is the first category and the one already in place is marked and not pickable. Only the tiles about to come into view are rendered, so the picker stays the same weight as the library grows.

How the fill works. The site's menu holds Rewrite all copy and Re-place all pictures for doing either step again by hand (a section you typed into is left alone). Each section is written by its own streamed call, a page's sections in parallel, every copy slot against the section's recorded slot schema (each slot knows its role, its placeholder and its character budget), and briefs every picture slot twice: keywords for a stock search and a rich prompt for generation. Pictures then climb the ladder: a matching photo in your library wins, else stock, else generation, the last two only where your brand's image settings allow them, and a picture used once on the site is never used again. Your library's own finished ads are never offered — an AI-produced ad carries its campaign's words in its name, tags and premise, so it outranks a real photograph of the subject and the page ends up showing an ad inside itself. They stay in the library and in search; they are simply not picture material. The fill is durable. It survives a closed tab, and the canvas re-renders each page as its fills land. Every picture then has its basics in the rail: ratio, position, fill mode, shape and a darken slider, each stored on the slot and kept when the picture is replaced or re-filled. A slot nothing has filled yet shows a glyph that says whether an image or a video goes there. Your logo is a slot too, and it is never treated as a picture. Every navbar and footer carries a mark slot whose empty state is the wordmark text; the sitemap pass and every page fill put your brand's own horizontal mark there from the logo system, choosing the on-dark version for an inverted band or a dark scheme and the on-light one everywhere else, and only where the slot is still empty. The rail's Brand logo places it by hand, Replace takes any mark from the library (SVGs included), Remove shows the wordmark again, and a brand-placed mark follows the section's surface when you change it. The customers' marks in the logo sections are slots as well, twelve at most, that you fill from the library; nothing generates one. Links are slots too: the fill names the page each link leads to, by slug, so the navbar's links open the site's own pages, a call to action leads to the page where the reader does the thing, and the wordmark leads home. The rail's Links section changes any of them to another page or a URL, the full-size preview follows them between pages (its page tabs and address follow along), and the exported pages link each other as files.

The Wireframe and Design views show every page as a live render on a zoomable board. Click anything: a headline or a paragraph selects that text and the rail opens on its field, ready to type; a picture selects it and the rail shows its settings; the rest of a section selects the section. Click the selected text again to edit it in place, and the Ask AI chip on it rewrites that one line from a direction. There is no zoomed-in editing mode: zoom the board as far as you like. Drag a section to move it: press anywhere on it, or on the grip in its toolbar, and move. The section itself rides the pointer and a grey placeholder of its own height holds its spot; move past a neighbour and they swap, the neighbour sliding out of the way, on the same page or across pages (the origin closes up, the target opens a slot). What you see while it is in the air is what dropping commits, the board scrolls when you near its edge so a far page is in reach, and Escape puts everything back. Open full size in the page's rail opens the page as a real document, where accordions open and selects drop.

Clips and animated SVGs

A picture slot holds a raster, an SVG or a short clip. Upload an mp4 or webm to the asset library (it is filed as a video: its own filter, first frame in the grid, plays on hover) and pick it from the rail's Replace like any picture. On the page it plays muted, looping and inline with no controls, at the slot's own shape, with the same ratio, position and darken controls as a photograph. An animated SVG needs nothing special: it is a picture, and the browser plays it. Over MCP a clip is images.<slot> = { url, media: "video", poster? }. Clips are never offered to the automatic picture pickers and are never analyzed.

Subpages, and one page per person

A page can sit under another page. The sitemap has three levels: the home page, the pages under it, and each page's subpages. Add a subpage with the round + under a page, or pick Sits under in the page's rail. A subpage's address carries its parent (/services/strategy); slugs stay unique across the site, so a link still names a page by its slug. It goes one level deep: a page with subpages stays at the top level, and deleting a page moves its subpages up rather than deleting them. Dragging a page's title strip moves it among its siblings (a page moves with its subpages); dragging a subpage under another page re-parents it.

A page's layout can be the starting point for its siblings. A site with an Events page or a Cases page gets a new subpage for every event or case, and they all look alike. Build one, select it and choose Use this layout for new pages in its rail. From then on the + under its parent (shown with a copy icon, and its tooltip names the layout) adds a page with the same sections, surfaces and settings, showing each section's placeholder text instead of the words. Its sections are locked, so opening the Wireframe view does not write copy into them: type over the placeholders, or unlock a section or regenerate it in the rail to have it written. The layout is a snapshot, so editing or deleting the page it came from changes nothing; select that page again and choose Update from this page to refresh it, or Stop using a saved layout. The site's shared navbar and footer come along as they are.

Dynamic pages carry a Dynamic badge and take no subpages. A page built once per person (below) is filled from records when Polyther publishes the site, and the level under its address belongs to those records (/profil/asa-oberg). So it shows a Dynamic badge on both boards, has no + under it, cannot be picked under Sits under, and a page dropped on it does not become its subpage. A page that already has subpages cannot become one per person until they are moved.

One page per person. A site with a team usually wants a page for each person: the portrait, the role, the bio, the ways to reach them. Building sixty pages by hand is not the answer, so a page can be a template: in the page's rail, tick Build this page once per person. The site then renders that page once for every person in the brand's People records (everyone, or one department or tag) at /<page>/<person>, for example /profil/asa-oberg. Names are folded to plain letters (Åsa Öberg → asa-oberg), two people with one name get -2, and an address never moves when the team is re-sorted or the filter is narrowed.

• Give the page a section from the Profile family (the rail's Add a profile section adds the first; Change block… shows the others). There are four page layouts so person pages do not all look alike: Profile 1 · Split (portrait beside the text), Profile 2 · Centered (a round portrait over a centered bio), Profile 3 · Statement (the name set huge, then portrait, bio and contact in three columns) and Profile 4 · Sidebar (a long bio as an article with the portrait and contact details in a card beside it). Profile 5 · Card is a compact band for ordinary pages that introduce one person. That block, and any contact band on the page, shows whoever the page is for. A field the record leaves empty is left out, never filled with placeholder text, and a contact row with nothing in it disappears.
• Every team list on the site links each name to that person's page, as soon as the list is bound to people. A site without a person page gets no link at all, never a dead one. The links follow a renamed person, a moved page and a changed filter.
• The canvas shows the template filled for one person; Preview as in the rail flips between people without saving anything. The full-size preview navigates from the team list to a person and back.
• The words come from People. A person has a long bio (as many paragraphs as it needs, a blank line between them), which their own page shows in full, and a short intro that team cards show. With no intro written, a card uses the bio's opening sentences, so a long bio never spills out of a card. Edit either under People and every page follows.

A site has one person page, and the home page cannot be one.

The rail

A section's rail holds its variant, its surface, its description, its copy slots as fields, and its pictures with Replace (from the library, uploads included) and Remove; a mark slot adds Brand logo. Typing into a copy field locks the section: a later page fill leaves it alone. Regenerate section takes a direction, "warmer", "shorter", "a photo of the oven instead", and re-fills that one section, lock or not, since pressing it means it. A page's rail carries its title and description, Generate this page, and Open full size.

People. A section that shows someone — a contact card under a call to action, a team list, the lead of a service — carries a People block in its rail. Pick a person for a card, or fill a team list from everyone, a department or a tag, and the list grows to fit. Bound fields are written from the record and follow it: change a phone number on the People page and every page that shows it moves. Typing into a bound field unbinds that card, because the words you type beat the record. When a site is filled, a team list nobody has bound takes the brand's people by itself, and the copy pass never writes a bound field, so no colleague is ever invented.

Lists. Most sections carry a list: FAQ items, features, plans, team members, nav links, a footer column's links. A list ships at the length the section was designed for and shows as many items as you want within its bounds. The rail's Lists section grows or cuts each list (nested lists sit under their parent), and each item's header in Copy removes that one item; a new item starts as the section's placeholder, click-to-editable on the page, and Ask AI on its slot or Regenerate section writes it. A navbar's links list is made as long as the site has pages when a page is filled.

Two people, or a person and the fill, can write to a site at once. Every write is compare-and-set and lands on a section by its identity, never its position, so reordering while a fill runs loses nothing. Moving pages around the board and zooming it are not edits to the site, so looking around while a fill runs never gets in its way.

Export

Export in the editor's top bar downloads the whole site as a zip, from any view. Pick a format and the download starts; a short getting-started card then says what to do with it.

• React is a drop-in for a Next.js + Tailwind 4 + shadcn/ui project: src/app/ holds one page.tsx per page, src/components/sections/ the sections they use, src/brand/ the brand's tokens, style guide and shadcn theme. The README inside lists the five setup steps.
• HTML is one document per page beside a css folder (the brand, the sections' layout utilities already compiled, motion). Open index.html; there is nothing to build and no Tailwind to set up. The pages are static: forms, accordions and menus carry no JavaScript.

The card also has Copy instructions: one text to paste into Claude Code, Codex or Cursor. It says where the zip is, what it holds, the versions it was built for, the steps, and the rules that are easy to break. Both zips carry the same text as AGENTS.md.

Pictures and fonts load from braaand in both; download them into the project before you publish. The same zip over REST: GET /api/brands/{brandId}/sites/{siteId}/export?format=react|html.

Every section also has a code view of its own: Design System → Sections, then Image | Code above the preview (HTML or React, one Copy). Stock beside it shows the section with nothing of the brand on it.

As part of the design-system bundle

The built pages ride the design-system export. export_design_system({ siteId }) over MCP, braaand sites export <brandId> <siteId> --out ./brand on the CLI, or ?site=<siteId> on the export route add:

• sites/<slug>/pages/<page>.tsx — the page component: each section under a SectionFillProvider carrying its copy and pictures as data, importing from @/components/sections/.
• sites/<slug>/pages/<page>.html — the same page as static markup for any other stack.
• sites/<slug>/site.json — the whole document, picture URLs absolute.
• The sections the site uses, _fill.tsx included, and the style guide beside them.

The pages carry no styling of their own. They look right the moment the brand's style guide CSS is in the project, which is what makes them portable to a Next.js app or a plain site.

Publishing to Polyther

A built site also leaves as ONE document, the site package — GET /api/brands/{brandId}/sites/{siteId}/package (a brand token works; ?theme=<id> resolves the brand through a theme first). It is what Polyther imports and publishes as the client's site: the same markup as the static export, every section marked with its identity so it stays an editable block in Polyther, site links as root paths, every picture as a public URL with its asset id, and the CSS that makes it look right with no build step — the sections library's compiled utilities and the brand's own sheet — plus the brand as shadcn tokens, its motion package and the site chrome as data.

Three rules govern the handoff. Braaand owns the look, Polyther owns the logic: Polyther recognises a logic-bearing section — an Agera signup — and binds the client's own form logic from its site settings, so editors there can change copy, look and effects but not what the form does. Tokens and site overrides always win: the brand sheet is a managed theme layer under the site's own tokens. A section stays a block: reorder, swap, Ask-AI-per-slot and the editor bridge all work on it in Polyther. When Polyther reports back, get_site shows publish — the site slug, the site version it holds and when — so a later edit here is visibly ahead of what is live.

The same package renders anywhere else too: a Next.js + Tailwind 4 project takes the .tsx pages and the style guide, a static host takes the .html twins and the two CSS strings. Only the logic binding is Polyther's.

For agents

The whole flow is on MCP, the REST API and the CLI.

REST: GET/POST /api/brands/{brandId}/sites (imageSource on create), GET/PATCH/DELETE …/sites/{siteId} (X-Doc-Version for compare-and-set; imageSource, themeId and styleGuide patchable, null clears), POST …/sites/{siteId}/generate ({ scope: "sitemap", pageCount?, importUrl? } — with Accept: application/x-ndjson it streams { t: "plan", pages } partials before { t: "done", site } — or { scope: "pages", stage?: "copy" | "pictures" }), POST …/sites/{siteId}/sections/{instanceId}/regenerate, GET …/sites/{siteId}/package (the site package Polyther imports). CLI: braaand sites list | get | create [--page-count 2-5] [--import-url …] [--image-source brand+stock+generate] | generate --wait [--stage copy|pictures] | regenerate | export | style [--theme] [--style-file] [--reset] | delete.

Generation is metered like the other analysis passes (Free plans draw on the lifetime sampler); pictures meter themselves through stock or image generation. A site whose Pictures from (or whose brand's policy) allows no source still fills its copy; its picture slots stay grey until you place something.

A site's own look

The brand's design system is the reference for every site. A site may differ in two ways, both stored on the site and both resolved in one place (resolveSiteBrand: brand, then theme, then site):

• themeId: one of the brand's themes, for a campaign look with its own faces and colours.
• styleGuide: the site's own overrides over the brand's style guide, in the same shape (elements per tag, structure, buttons, forms, links, display, eyebrow, typeRatio). Only what is stated differs; everything else follows the brand, including later changes to it.

The overrides are style guide only. They cannot move an ad or another site, and they never touch the brand. The editor's canvas, the full-size preview, the site package (site.ownStyles: true), the React and HTML zips and export_design_system({ siteId }) all ship the site's resolved stylesheet; files in such an export say site <id> v<N> (own styles) in their banner. The brand's own export, the synced dist/ folder and the shadcn registry stay the brand's.