How SOSEI Rebuilds a Website in Under Three Minutes

Most people’s mental model of “AI-generated website” is a single ChatGPT prompt followed by a wall of generic markup. That’s not what happens here. A SOSEI rebuild runs through five distinct AI stages, parallelised in the middle, with a deterministic renderer at the end. The whole thing completes in under three minutes for a typical small-business site — and the engineering choices that make it reliable are worth unpacking.

Stage 0: Scrape

Before any AI runs, the source site has to be understood. A parallel BFS crawler — Cheerio over node-fetch, up to 15 pages, 5 concurrent — pulls every page reachable from the homepage and extracts:

• Visible text, structured by heading hierarchy.
• Image references, with their natural dimensions.
• Brand: colour palette, fonts in use, logo SVG, favicon.
• Tracking codes: GA, GTM, Meta Pixel, Hotjar, LinkedIn Insight, TikTok Pixel, Plausible, Umami, Clarity.
• E-commerce detection: Shopify, WooCommerce, BigCommerce, Magento, Wix, Squarespace.

Every image — including the logo and favicon — is then re-fetched and uploaded to Supabase Storage. This is the step that makes downstream generation safe: no AI prompt ever references an external image URL that might fail at render time, and the rebuild keeps working if the original site goes offline.

Stage 1: Plan

The first AI call — Claude Haiku 4.5, the cost-tiered structural model used in both quality tiers — receives the entire scrape and produces a structured site plan:

• The page list (Home, About, Services, Contact, plus industry-specific pages like “Portfolio” or “Menu”).
• The detected industry IDfrom a 161-entry catalog. This drives downstream design and copy choices — a dental clinic and a metal-fabrication shop get different colour palettes, typography registers, and section orderings.
• The recommended font pairing from the 21-font self-hosted pool, chosen to be the closest mood-match for the source site.
• A brand-style summary (formal / playful / authoritative / minimal / etc.).

Stage 2: Voice card

Before any page is written, a separate, short AI call produces a frozen voice contract— the tone, rhythm, person, vocabulary, and recurring phrases of the source site. This document is then passed as input to every parallel per-page copywriting call in stage 4.

Why a separate step? Because LLMs drift. Ten pages written by ten parallel invocations of the same model, without a shared voice contract, end up sounding like ten different writers. Lock the voice once, before parallelism starts, and every page reads like it came from the same author. See Preserving Your Brand During a Rebuild for the full picture.

Stage 3: Design system

Two AI calls build the visual layer. The first produces design tokens (colour, typography, radius, spacing, shadow), a mood descriptor, a style profile (“editorial”, “swiss”, “playful”), and a motion profile (“subtle”, “none”, “expressive”). The second composes the global header and footer HTML.

The tokens then run through a deterministic normalizeTokens pass that enforces WCAG contrast ratios (AAA 7:1 on body, AA 4.5:1 on muted) and fills any omitted tokens from the catalog palette. The AI cannot output an accessibility-violating design system because the renderer rejects it.

Stage 4: Page fan-out

This is where the parallelism happens. Each page in the plan gets its own AI invocation, all running concurrently. The input to each is: the scraped source content, the voice card, the design tokens, and a section schema. The output is a JSON list of typed sections — hero, features-icons, testimonials, cta-band, etc. — with their props.

Critically: the LLM never writes HTML or CSS. It chooses sections and writes copy. The renderer owns the DOM. This separation is what makes the output reliable: a model that hallucinates a misclosed <div>can’t break the build because it’s not writing tags.

Stage 5: Legal pages (in parallel)

While the main fan-out is running, a separate Haiku call writes the six legal pages in one shot: privacy policy, terms of service, cookie policy, impressum, accessibility statement, and the 404 page. These run in parallel because they don’t depend on the per-page copy — only on the source-site metadata (company name, address, email) and language.

The legal generator has its own JSON-recovery layer because Opus occasionally emits invalid JSON in long-form legal output. If the parse fails, an auto-healing pass is invoked inline at publish time and again as a manual button in the dashboard — ensuring no site ever ships without legal pages.

Stage 6: Host

Everything assembles into a hosted site: index.html, every inner page, style.css, _header.html, _footer.html, sitemap.xml, robots.txt (with explicit allow rules for all 18 major AI crawlers), llms.txt, and the legal pages. All saved into a versioned row in Postgres and served live at https://…/s/[slug]/….

What the quality switch actually toggles

The dashboard’s “Best” vs “Fast” toggle swaps the model used for the taste stages — design system, per-page copy, and chat-edit. Best runs Claude Opus 4.8 (~3 min on a typical site); Fast runs Claude Sonnet 4.6 (~1 min). The structural stages — plan, voice, and legal — run Claude Haiku 4.5 in both tiers, where a bigger model wouldn’t change the output.

Logo vision is always Haiku 4.5 — the smaller model is more than sufficient for “extract 2–3 dominant hex codes from this image,” and using a larger model would only add cost.

What the renderer never delegates to AI

Several decisions are not made by the LLM at all, because they are easier to get right deterministically:

• Section variant assignment. siteVariantAB(siteName) and pageHeroVariant(siteName) hash the site name into a stable A/B/D choice. All inner pages of one site share the same variant, so the site feels coherent without the LLM having to remember.
• Section-header alignment.Centred or left-aligned for the whole site, picked deterministically. Mixing both within a site looks unintentional — the deterministic pick prevents that.
• Contrast token correction.If the LLM’s chosen foreground hits only 4.0:1 against the surface, the renderer auto-darkens it to clear AAA. The LLM cannot ship an inaccessible palette.
• Image sizes, alt text presence, dimensions. The renderer’s imgTag helper throws if alt text or explicit dimensions are missing. The LLM has to provide them.

Why this matters for what you see on launch day

The result of all this engineering is the only outcome the customer actually cares about: a site that looks like itself, works on every device, scores high on every audit dimension, and ships in three minutes instead of three months. Every step in the pipeline exists because removing it produced a measurable regression in some real-world rebuild.

If you’ve only ever seen “AI website builders” as a curiosity, the SOSEI rebuild is worth trying as a benchmark. Start a project with one URL and judge the output.