Landing page builder

Typed blocks and composition rules

The library has 27 block types and 244 variants: header, product gallery, price, benefits, FAQ, guarantee, delivery date, colour and size picker, order form, footer and more. Every variant describes itself: its text fields with their limits, its settings, the events it fires, how it renders and its own quality record.

1. The settings panel is generated from each variant's description, and text fields show their limits and errors while the operator types.
2. Composition rules run in the browser and on the server, so the editor flags a problem as it happens and the export refuses it for the same reason: at most one order form, placed before the finish; a block that shows a result only after the block that produces it; no page without a way forward.
3. Switching a variant keeps the texts and settings that still fit and sets the rest aside, so switching back restores them.
4. Editing is built for speed and safety: drag and drop with keyboard and menu alternatives, a command palette, 100-step undo and autosave every second with conflict detection.

AI-written copy, checked before it is used

An AI step writes every text field of every block, code checks each field, and only the fields that fail are asked again. Copy is handled as data with rules, not as free text. For the photos, a vision model picks the usable product images and a local model removes backgrounds in a separate process.

1. A plan lists every field of every block with its length limit, required placeholders such as the price, and a short note on what the field is for.
2. Each field is checked in code: length, number of items, required placeholders and language.
3. Only failing fields are asked again, with the rejected answer and the reason, for a limited number of rounds. A new answer replaces the old one only if it is better; a field that still has an error stops the job instead of reaching the page.
4. Single blocks can be filled or rewritten on demand, up to 10 blocks per request within 120 seconds.
5. Several model providers are supported, and the default model is picked by measured cost. Two measured runs for a full page: $0.03–0.05 in model cost and 66–100 s.

Interactive game blocks

The library includes interactive game blocks for engagement: short, playful steps that keep the visitor moving through the page. Six game variants share one game kit, so a new game adds only its own look and logic.

1. Games and the guided product quiz are action blocks: they lead the visitor forward, and the blocks that depend on them appear only after they are completed.
2. Answers and choices carry over to later blocks during the visit, kept in the browser's session storage rather than on a server.
3. Each action block has its own driver, so the automatic run in a real browser plays it to the end the way a visitor would.

Themed design sets

Design sets for different occasions and seasons: 56 page designs in total, one core design plus five designs for each of 11 occasions. Each themed design has its own page structure and AI-generated hero artwork, and any page can be restyled without touching its blocks.

1. A style panel sets colours, corner radii and text size, and can take the logo and colours from a saved store preset.
2. Readability is enforced: label colours follow a contrast rule, and a theme cannot put text on a background where it would be hard to read.
3. Four open-licence font families ship with the page, subset to the scripts it uses, so no font service is needed.
4. Designs are versioned and frozen by a content hash. A page can be updated from a newer version of its design, with the difference applied as one undo step; saving a page as a template requires the pre-flight checks and an automatic browser run through the page.

Automated quality gate

A variant enters the library only after a real browser has rendered it at 390 × 844 px in 9 render scenarios: three languages (English, long German at the field maximum, long Arabic right to left) in three colour palettes. All 244 variants pass.

Illustration. The 9 render scenarios behind each variant's quality stamp.

1. Checks in every scenario: no horizontal overflow, text contrast of at least 4.5:1 and controls large enough to tap.
2. Action blocks such as games, quizzes and forms are played to the end in the browser.
3. A passing variant gets a stamp with the hash of its files, the hash of the rendering engine and the browser version. Changing the engine marks every stamp stale, and a fast test fails until all variants are checked again.
4. Beyond single blocks: an automatic run through whole exported pages, browser tests of the editor at 1440 and 390 px, and a linter that enforces the interface's design rules.

Static export with a pre-flight check

Before a package is built, a pre-flight runs 10 groups of checks. The result is a static page: every image, font and script ships inside the package; an external asset URL stops the export. The builder never receives contact details or visitor data: the exported page is hosted elsewhere.

1. Checks cover the composition rules, texts, block data, leftover template markers, placeholders, language and text direction, and font licences.
2. A refusal lists every reason at once, each with a link to the place to fix it. Over-long text and pages above 500 KB raise warnings.
3. The live preview runs in a sandboxed frame: it never sends a form and never ends up in the package.
4. Images are re-encoded to WebP, capped at 2,400 px and stored once by content hash.