← All documents Architecture and delivery plan · Proof of concept

Frame Pilot AI

An internal platform that turns a Figma design into a responsive, multi-page Next.js website, checks its quality, publishes the code to GitHub and returns a verified live preview.

Figma link→Design specification→Site plan→Generated code→Sandbox build and tests→Repair→GitHub commit→Live preview
Version 0.4 draft for client review Date 23 October 2026 Scope Planning only, no build started
Every technology named in this report is a proposal until it is approved.
01 · Executive summary

A controlled path from design to deployed website

Frame Pilot AI converts an approved Figma design into a complete Next.js website. It reads the design through Figma's official API and writes a structured specification. From that it plans the site, generates readable source code, and builds and tests the result in an isolated sandbox. It repairs common failures within a fixed limit, commits the code to your GitHub organisation and deploys a preview on Vercel. Every run ends with a live URL and a quality report, or a clear explanation of why it stopped.

The proof of concept (POC) demonstrates this full journey on real designs from your team in 16 weeks, delivered by a dedicated team of three: a full-stack engineer, an AI engineer and a DevOps engineer with full-stack skills. Proven tools handle builds, testing, publishing and deployment. AI handles four narrow tasks: understanding the design, planning the site, writing components, and making small targeted fixes. Generated code never runs on the platform's own servers, and nothing reaches production without passing a quality gate and a human approval.

7architecture verticals, each with its own plan and exit criteria
4narrow AI responsibilities; everything else is deterministic
15automated quality checks, split into hard gates and soft warnings
16weeks to a demonstrated POC, with a dedicated team of three engineers
02 · Problem and approach

Why build Frame Pilot, and how we keep it dependable

The problem today

  • Developers rebuild layouts, spacing, colours and responsive behaviour from Figma by hand for every site.
  • Repository setup, build configuration and hosting are repeated for each project.
  • Accessibility, broken links and mobile layout problems are often found late, or by the end client.
  • Quality varies by developer, and there is no shared evidence of what was checked.

What Frame Pilot changes

A single run takes a Figma link and returns a deployed preview, the source code in your GitHub organisation, and a report that shows exactly what passed. The code is conventional Next.js that your developers own and can extend. There is no proprietary runtime and no lock-in.

Design principles

Vertical slice first

One real design flows through every stage before any stage is made elaborate.

Deterministic by default

Builds, tests, git and deployment use standard tooling. AI is limited to interpretation, planning, code writing and targeted repair.

Untrusted until checked

Design content and AI output are treated as untrusted input. Generated code runs only in a sandbox that holds no credentials.

Observable and bounded

Every run has a timeline, stored artifacts, usage figures, and caps on time, AI usage and repair attempts.

Measured, never assumed

Results are reported as pass, pass with warnings or fail, with metrics. A site that compiles is not called production-ready.

Replaceable parts

The UI library, AI provider, database, job engine, sandbox and hosting provider each sit behind an interface.

03 · Objectives and scope

What the POC must prove

  1. Convert real Figma files into multi-page, responsive Next.js sites using the App Router and TypeScript.
  2. Validate every site automatically: build, types, routes, runtime errors, links, assets, mobile layout, accessibility and visual similarity.
  3. Repair common failures automatically within a fixed number of attempts, with a complete audit trail.
  4. Publish to GitHub and deploy a verified preview on Vercel, returning the URL, commit and report.
  5. Show that runs are observable, cancellable, recoverable after a crash and bounded in time and cost.
  6. Produce measured results and a credible path to production.

In scope

  • Marketing and content websites: home, about, pricing, services, contact, listing pages
  • Desktop and mobile layouts, with documented rules when a mobile design is missing
  • Navigation, mobile menus, dialogs and in-page anchors shown in the design
  • Accessible front-end forms with validation (no submission backend)
  • SEO metadata, images, icons and self-hosted fonts
  • GitHub publishing, Vercel previews, gated production promotion and rollback

Out of scope for the POC

  • Backends, databases, sign-in or payments inside generated sites
  • CMS integration and two-way sync with Figma
  • Public multi-customer SaaS, billing and custom domains
  • Pixel-perfect guarantees for every design
  • Automatic production releases without human approval
04 · Users and user flows

Who uses Frame Pilot and how a run feels

Operator

A developer or project owner who creates projects, starts runs, answers questions and publishes previews.

Designer

Prepares the Figma file, reviews the detected pages and compares the result with the design.

Approver

A lead who reviews quality evidence and approves production releases or triggers a rollback.

Viewer

A stakeholder with read-only access to runs, reports and preview links.

The journey at a glance

  1. Create a project

    YouName it, paste the Figma link, keep or change the defaults.

    Frame PilotApplies sensible defaults for every optional setting.

  2. Confirm pages

    YouCheck the pages and web addresses it found.

    Frame PilotVerifies access, scores frames as pages and pairs desktop with mobile.

  3. Watch the run

    YouFollow the live timeline, or leave and come back.

    Frame PilotAnalyses, plans, writes code, builds and tests in a sandbox.

  4. Answer questions

    YouAnswer short multiple-choice questions, only if the design is truly ambiguous.

    Frame PilotPauses only when a wrong guess would waste the run.

  5. Review evidence

    YouRead the QA report and screenshots beside the Figma renders.

    Frame PilotRecords every check, repair and decision.

  6. Open the preview

    YouOpen the live URL on desktop and phone, and the GitHub commit.

    Frame PilotPublishes, deploys and re-tests the live preview.

  7. Release

    YouAn approver promotes to production, or keeps it as a preview.

    Frame PilotChecks the release gate and health, with one-click rollback.

Main user flow

User actionPlatform stepAI stepExternal serviceDecision or gateSuccessStop or failure
flowchart TD
  A(["Open the dashboard"]):::user --> B["Create project: name, Figma link, preferences"]:::user
  B --> C{"Link valid and file shared?"}:::gate
  C -->|"No"| C1["Shown how to fix: correct link or share file"]:::risk
  C1 --> B
  C -->|"Yes"| D["Review detected pages and suggested routes"]:::user
  D --> E{"Pages look right?"}:::gate
  E -->|"Adjust"| D1["Rename, merge or exclude frames"]:::user
  D1 --> D
  E -->|"Confirm"| F["Start generation"]:::user
  F --> G["Live timeline: analyse, plan, write code, build, test"]:::core
  G --> H{"Blocking question?"}:::gate
  H -->|"Yes"| H1["Answer a multiple-choice question"]:::user
  H1 --> G
  H -->|"No"| I{"Quality gate passed?"}:::gate
  I -->|"No"| I1["Automatic repair, up to 3 attempts"]:::ai
  I1 --> I
  I -->|"Still failing"| X["Run stops with a full report"]:::risk
  X --> X1["Retry, adjust settings or fix the design"]:::user
  I -->|"Yes"| J["Commit to GitHub and deploy a preview"]:::core
  J --> K["Re-test the live preview"]:::core
  K --> L["Review preview, repository and report"]:::user
  L --> M{"Ready for production?"}:::gate
  M -->|"Not yet"| N["Keep as preview and share the link"]:::user
  M -->|"Approver signs off"| O["Promote to production"]:::ok
  O --> P["Health checks pass, rollback stays one click away"]:::ok
  classDef user fill:#F1E7D3,stroke:#B89B6A,color:#3B2F1E
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ai fill:#0F766E,stroke:#0B4F4A,color:#FFFFFF
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
Main user flow. The user makes three decisions: confirm the pages, answer questions when asked, and approve production. Everything between those points runs on its own and can be watched live.
flowchart TD
  A["Design specification built"]:::core --> B{"Type of ambiguity"}:::gate
  B -->|"Blocking"| C["Pause and ask up to 5 questions"]:::user
  C --> D{"Answered within 72 hours?"}:::gate
  D -->|"Yes"| E["Resume planning with the answers"]:::ok
  D -->|"No"| F["Run ends: question timed out"]:::risk
  B -->|"Warning"| G["Apply documented default, flag in report"]:::core
  G --> H["Acknowledge before production"]:::user
  B -->|"Info"| I["Recorded in the log only"]:::core
  classDef user fill:#F1E7D3,stroke:#B89B6A,color:#3B2F1E
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
Clarification flow. Blocking examples: no frame looks like a page, or two frames compete for the same address. Warnings include a missing mobile design or a social link without a URL.
flowchart TD
  R["Run in progress"]:::core -->|"User cancels"| C1["Stop at the next safe point"]:::core
  C1 --> C2["Abort AI and sandbox work"]:::core
  C2 --> C3["Status: cancelled"]:::risk
  R -->|"Worker crashes"| W1["Heartbeat goes stale"]:::risk
  W1 --> W2["Current stage is queued again"]:::core
  W2 --> W3["Resumes from last checkpoint, no duplicates"]:::ok
  R -->|"Run fails"| F1["Status: failed, evidence attached"]:::risk
  F1 -->|"User retries"| F2["Resume from last completed stage"]:::core
  F2 --> R
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
Run control flow. Cancel, crash recovery and retry all resume from saved checkpoints. A retried run never creates a second repository, commit or deployment for the same work.
05 · System architecture

Seven layers, three trust zones

The platform is split so that the parts holding credentials never run generated code, and the parts that run generated code never hold credentials. The dashboard and API record every run in a database. A background worker coordinates the pipeline and is the only component that talks to Figma, the AI provider, GitHub and Vercel. Generated code is built and tested only inside disposable sandboxes.

L1

Dashboard

Project setup, live progress, logs, preview, QA reports, repository and deployment details, retry and cancel.

Trusted
L2

Control plane

Versioned API, sign-in and roles, durable run state, job scheduling, progress events, audit log, usage limits.

Trusted, holds secrets
L3

AI orchestration

Design interpretation, site planning, code generation, targeted repair, behind a replaceable provider interface.

Trusted process
L4

Figma integration

Access checks, version-pinned extraction, rendering, asset download, design specification, change tracking.

Trusted process
L5

Isolated execution

Scaffold, install, build, type check, browser tests, screenshots, patch and retest, then clean up.

Untrusted, no secrets
L6

Source control and deployment

Repository creation, commits, preview deployments, production promotion, live verification, rollback.

Trusted, holds secrets
L7

Storage and observability

Run state, history, artifacts, design specifications, logs, metrics, screenshots, QA reports, deployment records.

Trusted
flowchart TB
  user(["Internal user"]):::user
  subgraph CP["Control plane, trusted"]
    dash["Dashboard UI"]:::core
    api["API v1"]:::core
    db[("PostgreSQL: run state")]:::core
    queue[("Redis: job queue")]:::core
    store[("Artifact storage")]:::core
    worker["Worker: orchestrator and stage runners"]:::core
    secrets[["Secret store"]]:::core
  end
  subgraph EXT["External services"]
    figma["Figma REST API"]:::ext
    llm["AI provider"]:::ext
    gh["GitHub via GitHub App"]:::ext
    host["Vercel build and hosting"]:::ext
  end
  subgraph SB["Isolated execution, untrusted"]
    sandbox["Sandbox: install, build, browser tests"]:::risk
  end
  user -->|"HTTPS"| dash
  dash -->|"REST and live events"| api
  api --> db
  api -->|"outbox"| queue
  queue -->|"stage jobs"| worker
  worker --> db
  worker --> store
  api -->|"signed links"| store
  worker -->|"read design, render images"| figma
  worker -->|"structured prompts"| llm
  worker -->|"create repo, commit"| gh
  worker -->|"deploy and poll"| host
  worker -->|"files in, reports out"| sandbox
  host -->|"build exact commit"| gh
  sandbox -.->|"live smoke tests"| host
  secrets -.-> worker
  secrets -.-> api
  classDef user fill:#F1E7D3,stroke:#B89B6A,color:#3B2F1E
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ext fill:#FFFFFF,stroke:#8FA9A3,color:#17302C,stroke-dasharray: 4 3
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
High-level architecture. Durable state lives in PostgreSQL, and the queue only carries work. If the queue is lost, the platform rebuilds it from the database. Vercel builds directly from GitHub at the exact commit that passed testing.
06 · The seven verticals

Each vertical has its own scope, flow, technology and exit criteria

A vertical is a self-contained stream of work with a clear owner and interface. Verticals can be built and tested in parallel. They connect only through the contracts listed under each one.

Dashboard and user experience

V1 · Layer L1

What it does

  • Project creation with defaults
  • Page and route confirmation
  • Live run timeline with stage details
  • Specification, plan and QA report viewers
  • Screenshot comparison with Figma renders
  • Repository, commit and preview panels
  • Retry, cancel, promote and roll back

Key screens

  • Projects list
  • New project wizard
  • Run detail: timeline, logs, questions
  • Design specification: pages, tokens, components, ambiguities
  • Quality report: checks, metrics, diffs
  • Release: gate status, approval, history

Done when

  • A user completes the full flow without leaving the dashboard
  • Live progress resumes after a page reload or network drop
  • Every placeholder in a generated site is listed on screen
Proposed technology
Next.js 16 App Router, Tailwind CSS v4, shadcn/ui, Server-Sent Events for live progress Proposed
Connects through
Versioned REST API and the event stream (V2)

Control plane and workflow

V2 · Layer L2

What it does

  • Versioned API with runtime-validated requests
  • Sign-in, roles and audit log
  • Run state machine with legal transitions only
  • Job dispatch through a transactional outbox
  • Checkpoints, heartbeats and crash recovery
  • Idempotency keys so retries never duplicate work
  • Per-run limits on time, AI usage and repairs

Run stages

  1. Ingest design
  2. Build specification
  3. Plan
  4. Generate
  5. Validate
  6. Repair (bounded)
  7. Publish
  8. Deploy
  9. Verify deployment

Done when

  • Killing the worker mid-stage resumes the run automatically
  • Cancel stops a run within 30 seconds
  • A repeated request with the same key returns the original result
Proposed technology
API inside the dashboard app with logic in a shared core package; PostgreSQL for durable state; BullMQ on Redis for dispatch Proposed · Temporal for production later Deferred
Connects through
Database records, queue jobs carrying only IDs, workflow events

Figma ingestion and design specification

V3 · Layer L4
flowchart TB
  A["Figma link"]:::user --> B["Parse file key and frame ids"]:::core
  B --> C["Check access, read file outline"]:::ext
  C --> D["Score frames as pages, pair desktop and mobile"]:::core
  D --> E["User confirms routes"]:::user
  E --> F["Fetch selected frames, version pinned"]:::ext
  F --> G["Render frames, export icons, download images"]:::ext
  G --> H["Store assets with content hashes"]:::core
  H --> I["Normalise layout, styles, text, components"]:::core
  I --> J["Extract design tokens"]:::core
  J --> K["AI interpretation: roles, names, interactions"]:::ai
  K --> L["Validated design specification"]:::ok
  L --> M["Ambiguity list: blocking, warning, info"]:::gate
  classDef user fill:#F1E7D3,stroke:#B89B6A,color:#3B2F1E
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ai fill:#0F766E,stroke:#0B4F4A,color:#FFFFFF
  classDef ext fill:#FFFFFF,stroke:#8FA9A3,color:#17302C,stroke-dasharray: 4 3
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
Figma ingestion flow. Every extraction is pinned to a specific Figma file version, so a run can be reproduced exactly. Figma's image links expire after a few weeks, so assets are downloaded and stored immediately.

What the specification captures

  • Pages, suggested routes and confidence
  • Layout: Auto Layout direction, gaps, padding, sizing
  • Tokens: colours, type scale, spacing, radii, shadows
  • Components, variants and repeated patterns
  • Images, icons and fonts with hashes
  • Prototype interactions and inferred links
  • Reference renders for visual comparison

How pages are found

Not every frame is a page. Frames are scored on size, name, shared headers and footers, and prototype links. Frames named Components, Styles, Cover or WIP are excluded. Desktop and mobile frames with the same base name become one page with two layouts. The user confirms the result before anything is generated.

Done when

  • Three test files produce valid specifications
  • At least 95% of visible text is captured
  • Page detection matches the designer's expectation for at least 90% of frames
  • Re-running the same version makes no Figma calls

Account requirement. Figma limits API access by seat type. A token from a View or Collab seat allows only about 20 file requests per month, so the POC needs a token from a Dev or Full seat. Figma's Variables API is Enterprise-only, so design tokens are derived from styles and layer properties instead.

Proposed technology
Official Figma REST API with a read-only service token (OAuth app for production) Proposed
Connects through
Versioned design specification (format fpds/0.1) stored as an immutable document

AI orchestration and code generation

V4 · Layer L3
AI 1

Interpret the design

Assigns roles such as header, hero, card and button. Names sections and proposes routes.

AI 2

Plan the site

Decides routes, shared layouts, component boundaries, files and tests. Rule-based checks validate the plan.

AI 3

Write components

Writes one component or page at a time, given only the context that unit needs.

AI 4

Repair failures

Reads a specific failure and the files involved, then proposes a small patch.

flowchart TB
  S["Design specification"]:::ok --> P["AI plan: routes, layouts, components, files"]:::ai
  P --> V{"Plan checks pass?"}:::gate
  V -->|"No, one re-ask"| P
  V -->|"Yes"| T["Copy pinned starter template"]:::core
  T --> K["Generate tokens, fonts, assets, routes, metadata"]:::core
  K --> U["AI writes each component and page"]:::ai
  U --> C{"File checks: imports, unsafe code, exports"}:::gate
  C -->|"Fail, regenerate unit"| U
  C -->|"Pass"| M["Source snapshot, file manifest, report"]:::ok
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ai fill:#0F766E,stroke:#0B4F4A,color:#FFFFFF
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
Code generation flow. Mechanical work is done by ordinary code: design tokens, font files, image placement, routing and metadata. AI writes component bodies only, and each file is checked before it ever runs.

Generated site contents

  • Next.js App Router with TypeScript
  • One file per component, readable names
  • Design tokens as CSS variables
  • Optimised images, inline SVG icons, self-hosted fonts
  • Semantic, accessible markup and SEO metadata
  • Lockfile, build config and Playwright tests
  • File manifest and implementation report

When the design is incomplete

  • No mobile design: documented responsive rules, listed in the report
  • Social links without URLs: marked placeholders, never invented
  • Forms: front-end validation, submission shown as not connected
  • Commercial fonts: a fallback is used and flagged for a licence decision

Done when

  • Two of three test files build without any repair
  • Every planned route exists
  • No unsafe code and no unapproved packages
  • A four-page site generates in under 20 minutes (to be measured)
Proposed technology
Anthropic Claude Opus 5.5 with structured outputs, behind an in-house provider interface Proposed · cheaper models per task after measurement Deferred
UI library
shadcn/ui on Radix primitives with Tailwind CSS v4 by default, plus a plain-Tailwind option Proposed · Material UI adapter Deferred

Isolated execution, testing and repair

V5 · Layer L5

Sandbox rules

  • Runs as a non-root user with CPU, memory, process and disk limits
  • No credentials of any kind
  • Network open only to the package registry during install
  • No network during build and tests
  • Per-command time limits, 45-minute cap per run
  • Destroyed after use; artifacts copied out first

What runs inside

  • Dependency install from a pinned lockfile
  • Type check, lint and production build
  • Playwright browser tests at phone, tablet and desktop widths
  • Accessibility scan with axe-core
  • Screenshots for comparison with Figma
  • Patch, rebuild and retest during repair

Done when

  • The quality gate passes on at least two of three test files, with up to three repairs
  • Seeded faults are repaired in at least 80% of trials
  • No accepted patch ever breaks a passing check
Proposed technology
Hardened Docker containers locally and on a demo machine; Vercel Sandbox microVMs as the hosted option Proposed · gVisor hardening for production Deferred
Details
See Quality and repair for the checks and the repair loop.

Source control and deployment

V6 · Layer L6
flowchart TD
  A["Quality gate passed in sandbox"]:::ok --> B["Commit to a generation branch, record the commit"]:::core
  B --> C["Vercel preview deployment of that exact commit"]:::ext
  C --> D{"Preview ready?"}:::gate
  D -->|"Build error"| E["Store build log, report failure"]:::risk
  D -->|"Ready"| F["Live tests on the preview URL"]:::core
  F -->|"Fail"| G["Preview marked unhealthy"]:::risk
  F -->|"Pass"| H{"Release gate met and approver signs off?"}:::gate
  H -->|"No"| I["Remains a preview, blockers listed"]:::user
  H -->|"Yes"| J["Advance main branch to the tested commit"]:::core
  J --> K["Production deployment of the same commit"]:::ext
  K --> L{"Production health checks pass?"}:::gate
  L -->|"Yes"| M["Marked current and known-good"]:::ok
  L -->|"No"| N["Instant rollback to last known-good"]:::risk
  M -.->|"later incident"| N
  classDef user fill:#F1E7D3,stroke:#B89B6A,color:#3B2F1E
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ext fill:#FFFFFF,stroke:#8FA9A3,color:#17302C,stroke-dasharray: 4 3
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
Deployment and rollback. Preview and production are built from the same commit, so what was tested is what ships. Rollback reassigns the production domain to an earlier deployment without rebuilding.

Release gate

  • All hard quality checks pass
  • Preview verified for the same commit within 24 hours
  • Visual similarity meets the calibrated threshold, or each gap has a recorded waiver
  • Every warning acknowledged
  • No known critical dependency vulnerabilities
  • Human approval by an approver

GitHub access

A GitHub App installed on a dedicated organisation creates repositories and commits code with short-lived tokens scoped to one repository. No personal tokens are used, and no git credentials enter the sandbox.

Done when

  • Repository, commit and preview URL are recorded and visible
  • Repeating a publish creates no duplicates
  • Promotion produces a healthy production URL
  • Rollback restores the previous release
Proposed technology
GitHub App with the Git Data API; Vercel projects and deployments driven by API, status by polling in the POC Proposed · webhooks and other hosts later Deferred

Storage, observability and security operations

V7 · Layer L7

What is stored

  • Raw Figma snapshot per file version
  • Design specification and site plan, content-hashed
  • Every source snapshot, including each repair step
  • Logs, screenshots, diff images and QA reports
  • Repository, commit and deployment records
  • Append-only event and audit logs

What is measured

  • Stage durations and failure rates
  • AI tokens, sandbox minutes and Figma calls per run
  • Repair attempts and outcomes
  • QA pass rates by check type
  • Deployment success and rollback counts

Done when

  • Any run can be reconstructed from stored records alone
  • Logs carry run and stage identifiers
  • An automated scan finds no secrets in logs, prompts or sandboxes
Proposed technology
PostgreSQL 17; local file storage, then S3-compatible or Vercel Blob storage; structured JSON logs Proposed · OpenTelemetry tracing and Sentry for production Deferred
07 · Generation lifecycle

From submitted link to verified URL

sequenceDiagram
  autonumber
  actor U as User
  participant D as Dashboard and API
  participant W as Worker
  participant F as Figma
  participant M as AI model
  participant S as Sandbox
  participant G as GitHub
  participant V as Vercel
  U->>D: Submit project and Figma link
  D->>F: Check access and read outline
  alt Link invalid or not shared
    F-->>D: Access denied
    D-->>U: Explain how to fix
  else Accessible
    F-->>D: Pages, frames, version
    D-->>U: Suggested pages and routes
  end
  U->>D: Confirm and start
  D-->>U: Live progress stream opens
  D->>W: Queue first stage
  W->>F: Fetch frames, renders and images
  W->>M: Interpret design
  opt Blocking ambiguity
    W-->>U: Ask a question through the dashboard
    U->>W: Answer
  end
  W->>M: Plan the site
  W->>M: Write components and pages
  W->>S: Build and test
  S-->>W: Results and screenshots
  loop Up to 3 repair attempts while hard checks fail
    W->>M: Diagnose and propose a small patch
    W->>S: Apply, rebuild, retest
  end
  alt Quality gate failed
    W-->>U: Run failed, report attached
  else Quality gate passed
    W->>G: Create repository and commit
    W->>V: Deploy preview of that commit
    V-->>W: Preview ready
    W->>S: Live tests against preview URL
    W-->>U: Preview URL, commit and report
  end
End-to-end sequence. Validation is instant. Everything after Start runs in the background with saved checkpoints, and the dashboard follows it live.
flowchart TD
  S0(("Start")):::term --> Q(["queued"]):::state
  Q -->|"worker takes the job"| I(["ingesting design"]):::state
  Q -->|"cancelled before start"| CX(["cancelled"]):::bad
  I --> B(["building specification"]):::state
  B -->|"blocking question"| AW(["awaiting input"]):::user
  AW -->|"answered"| P(["planning"]):::state
  B -->|"no question"| P
  P --> G(["generating"]):::state
  G --> V(["validating"]):::state
  V -->|"checks failed, attempts left"| R(["repairing"]):::ai
  R -->|"patch kept or reverted"| V
  V -->|"quality gate passed"| PU(["publishing"]):::state
  V -->|"limit reached"| F(["failed"]):::bad
  PU --> D(["deploying"]):::state
  D -->|"preview ready"| VD(["verifying deployment"]):::state
  D -->|"deployment error"| F
  VD -->|"live tests passed"| OK(["succeeded"]):::ok
  VD -->|"live tests failed"| F
  F -.->|"retry from last checkpoint"| Q
  ANY(["any running state"]):::state -->|"cancel requested"| CC(["cancelling"]):::gate
  CC -->|"work stopped, sandbox removed"| CX
  classDef state fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef user fill:#F1E7D3,stroke:#B89B6A,color:#3B2F1E
  classDef ai fill:#0F766E,stroke:#0B4F4A,color:#FFFFFF
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
  classDef bad fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
  classDef term fill:#0B4F4A,stroke:#0B4F4A,color:#FFFFFF
Run states. Only the transitions shown are allowed, and each one is recorded. A cancel can arrive during any running state. If a worker crashes, its lease expires and the same stage resumes from its last checkpoint.
08 · Data and API

What the platform records, and how the dashboard talks to it

erDiagram
  PROJECT ||--o{ DESIGN_SNAPSHOT : captures
  PROJECT ||--o{ GENERATION : runs
  PROJECT ||--o| REPOSITORY : "publishes to"
  DESIGN_SNAPSHOT ||--o{ ASSET : contains
  DESIGN_SNAPSHOT ||--o{ DESIGN_SPEC : "normalised into"
  DESIGN_SPEC ||--o{ GENERATION : "input to"
  GENERATION ||--o{ STAGE_RUN : executes
  GENERATION ||--o{ SOURCE_SNAPSHOT : "versions code"
  GENERATION ||--o{ QA_RUN : "checked by"
  QA_RUN ||--o{ QA_CHECK : contains
  GENERATION ||--o{ REPAIR_ATTEMPT : "repaired by"
  GENERATION ||--o{ DEPLOYMENT : deploys
  GENERATION ||--o{ WORKFLOW_EVENT : emits
  PROJECT {
    text id PK
    text name
    text figma_file_key
    jsonb settings
  }
  DESIGN_SNAPSHOT {
    text id PK
    text figma_version
    text raw_sha256
  }
  DESIGN_SPEC {
    text id PK
    text schema_version
    text spec_sha256
  }
  GENERATION {
    text id PK
    text status
    text current_stage
    text qa_verdict
  }
  STAGE_RUN {
    text id PK
    text stage
    int attempt
    timestamptz heartbeat_at
  }
  SOURCE_SNAPSHOT {
    text id PK
    int seq
    text tree_sha256
  }
  QA_RUN {
    text id PK
    text target
    text verdict
  }
  QA_CHECK {
    text id PK
    text check_type
    text status
    real metric
  }
  REPAIR_ATTEMPT {
    text id PK
    text outcome
  }
  REPOSITORY {
    text id PK
    text full_name
  }
  DEPLOYMENT {
    text id PK
    text environment
    text commit_sha
    text url
    bool known_good
  }
  WORKFLOW_EVENT {
    bigint seq PK
    text type
  }
  ASSET {
    text id PK
    text kind
    text sha256
  }
Data model. The raw Figma snapshot is kept separate from the normalised specification, so the specification can be rebuilt without calling Figma again. Every repair step is a new source snapshot. Large documents live in object storage; the database keeps hashes and summaries.

Why PostgreSQL is proposed

Projects, runs, stages, reports and deployments are closely related, and state changes must be atomic: a stage completes, its checkpoint is saved, an event is logged and the next job is queued, all together. PostgreSQL does this natively and supports reporting with plain SQL. MongoDB remains a workable alternative if your team prefers it operationally, at the cost of weaker cross-record guarantees.

Live progress

The dashboard receives progress through Server-Sent Events: one-way, built into browsers, and able to resume from the last event after a disconnect. Commands such as cancel or retry use the normal API. WebSockets are not needed for the POC.

CapabilityEndpoint (API v1)WhoSafe to repeat
Create projectPOST /projectsOperatorYes, with idempotency key
Validate Figma link and accessPOST /figma/validateOperatorYes, read-only
Start generationPOST /projects/{id}/generationsOperatorYes, with idempotency key
Run statusGET /generations/{id}ViewerYes
Live progressGET /generations/{id}/eventsViewerResumes from last event
Cancel or retryPOST /generations/{id}/cancel, /retryOperatorYes
Design specificationGET /design-specs/{id}ViewerYes, immutable
Artifacts and QA reportsGET /generations/{id}/artifacts, /qa-runsViewerYes
RepositoryPOST / GET /projects/{id}/repositoryOperator / ViewerYes, returns existing repo
Deploy or promotePOST /generations/{id}/deploymentsOperatorYes, with idempotency key
Inspect deploymentGET /deployments/{id}ViewerYes
Roll back productionPOST /projects/{id}/production/rollbackOperatorYes, with idempotency key
09 · Quality and repair

Quality is measured on every run

CheckHowGatePass criterion
InstallPinned lockfile, offline package storeHardCompletes without error
Type checkTypeScript compilerHardNo errors
LintESLint with Next.js rulesHardNo errors; warnings reported
Production buildnext build with no networkHardCompletes without error
Route coverageRequest every planned pageHardAll pages return 200; unknown pages return 404
Browser errorsPlaywright console and page errorsHardNone
Broken links and assetsCrawl internal links, watch networkHardNone broken
Mobile and desktop overflow375, 768, 1280 and 1440 px widthsHardNo sideways scrolling at 375 and 1280
Accessibilityaxe-core on every page and widthHardNo critical or serious issues
Key journeysNavigation, mobile menu, dialogs, anchorsHardAll pass
Visual similaritySection-by-section comparison with Figma rendersSoftAt or above the calibrated threshold
SEO basicsTitle, description, language, one main headingSoftPresent
Performance signalsLargest paint and layout shift from browser tracesSoftReported only
Live smoke testKey checks repeated on the deployed URLHardAll pass

How visual comparison works

The browser window is set to the same width as the Figma frame, with the same pixel density. Animations are paused and fonts are loaded first. Each section of the page is compared with the matching area of the Figma render, rather than comparing whole pages. Layout measurements from the page add a second signal: positions, sizes, font sizes and colours. Results are shown as scores and highlighted difference images.

How thresholds are set

We run the pipeline on 10 to 15 representative designs. Two reviewers independently mark each section as acceptable or needing work, without seeing the scores. The thresholds that best agree with the reviewers are adopted and versioned. Until calibration is complete, visual similarity is reported but does not block. We do not claim pixel-perfect output.

flowchart TD
  A["Source snapshot"]:::core --> B["Sandbox: install, type check, lint, build"]:::core
  B --> C["Browser tests: routes, errors, links, overflow, accessibility, journeys"]:::core
  C --> D["Screenshot comparison with Figma"]:::core
  D --> E{"All hard checks pass?"}:::gate
  E -->|"Yes"| F["Verdict: pass, or pass with warnings"]:::ok
  E -->|"No"| G{"Attempts and budget left?"}:::gate
  G -->|"No"| H["Stop safely: failed, with full history"]:::risk
  G -->|"Yes"| I["Trace failures to responsible files"]:::core
  I --> J["AI proposes a minimal patch"]:::ai
  J --> K["Apply to a copy, rebuild, retest"]:::core
  K --> L{"Fewer failures and nothing newly broken?"}:::gate
  L -->|"Yes"| M["Keep patch as new snapshot"]:::ok
  L -->|"No"| N["Revert to previous snapshot"]:::risk
  M --> E
  N --> G
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ai fill:#0F766E,stroke:#0B4F4A,color:#FFFFFF
  classDef gate fill:#FFF6E0,stroke:#B7791F,color:#4A3410
  classDef ok fill:#DDEEE2,stroke:#2E7048,color:#173D26
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
Bounded repair loop. Simple fixes such as automatic lint corrections and missing imports run first and cost no AI usage. AI patches may touch at most five generated files and never the build configuration. The same failure seen twice is marked unrepairable. The default limit is three attempts.
10 · Security

Credentials and generated code never meet

flowchart LR
  subgraph Z1["Zone 1: trusted control plane, holds credentials, never runs generated code"]
    API["Dashboard and API"]:::core
    WK["Worker"]:::core
    SEC[["Secret store"]]:::core
    DB[("Database")]:::core
    OBJ[("Private artifact storage")]:::core
  end
  subgraph Z2["Zone 2: untrusted execution, runs generated code, holds no credentials"]
    SBX["Sandbox: limited resources, no network during build and test"]:::risk
  end
  subgraph Z3["Zone 3: external providers"]
    FIG["Figma"]:::ext
    LLM["AI provider"]:::ext
    GH["GitHub"]:::ext
    VC["Vercel build and hosting"]:::ext
  end
  SEC -.->|"short-lived, in memory"| WK
  SEC -.-> API
  API --> DB
  WK --> DB
  WK --> OBJ
  WK -->|"files only"| SBX
  SBX -->|"reports, treated as untrusted"| WK
  WK -->|"read-only token"| FIG
  FIG -->|"design content is untrusted"| WK
  WK -->|"design data, no secrets"| LLM
  LLM -->|"output is untrusted code"| WK
  WK -->|"token for one repository"| GH
  WK -->|"team-scoped token"| VC
  GH --> VC
  classDef core fill:#DCEFEA,stroke:#0F766E,color:#12302C
  classDef ext fill:#FFFFFF,stroke:#8FA9A3,color:#17302C,stroke-dasharray: 4 3
  classDef risk fill:#F6E1DD,stroke:#A63D36,color:#5A1E1A
Trust boundaries. Only the sandbox and Vercel's own build environment execute generated code, and neither receives our credentials. Generated sites need no secrets in the POC.
ThreatExampleControl
Unauthorised useSomeone outside the team starts runsSign-in through GitHub with an allowlist; viewer, operator and approver roles
Secret leakageGenerated code tries to read keysNo secrets in sandboxes or prompts; network closed during build and test; log scrubbing
Prompt injectionA Figma layer named with hidden instructionsDesign text passed as data; AI returns structured output only; static checks block scripts and unsafe code
Malicious packagesAI adds a look-alike dependencyApproved package list with exact versions; install scripts disabled; lockfile from template
Resource abuseInfinite loop or very large designCPU, memory, process and time limits; caps on design size and pages per run
Sandbox escapeContainer breakoutNon-root, no host access, reduced kernel features; microVM or gVisor isolation for hosted use
Untraceable changesWho released to production?Append-only audit log of every privileged action
11 · Technology choices

Options evaluated and what we propose

Each choice was compared on five criteria: time to a working slice, operational simplicity, correctness and durability, ease of replacement, and the path to production. Versions were checked against official sources on 23 October 2026 and will be re-checked when the build starts. No prices are quoted; usage costs will be measured during the POC.

AreaOptions comparedProposalReasonStatus
Generated site frameworkNext.js App Router (required)Next.js 16, TypeScript 6.0, Tailwind CSS 4Current stable line. TypeScript 7 is not yet supported by the lint toolchain, so 6.0 is pinnedProposed
UI componentsshadcn/ui, Material UI, Radix with custom styling, custom systemshadcn/ui, plus a plain-Tailwind optionshadcn/ui copies editable source into the project, so it can match any design and the client owns every line. Material UI's look needs heavy overriding for non-Material designsProposed
Platform databasePostgreSQL, MongoDBPostgreSQL 17 with DrizzleRelational data, atomic state changes, simple reportingProposed
Jobs and workflowBullMQ with Redis, PostgreSQL queue, TemporalBullMQ with Redis; run state in PostgreSQLMature and simple. Temporal is heavier and suits production once stages settleProposed
AI model and orchestrationDirect API with own workflow, AI SDK, agent frameworks, autonomous coding agentsClaude Opus 5.5 through our own provider interfaceStrong vision, long context and structured output. A fixed workflow is easier to audit than open-ended agentsProposed
Design sourceFigma REST API, Figma MCP server, Figma plugin exportFigma REST APIOfficial, headless, versioned and batchableProposed
SandboxDocker, Docker with gVisor, Vercel Sandbox, other microVM servicesHardened Docker; Vercel Sandbox for hosted useFast to build; microVM isolation available without running serversProposed
Source control accessGitHub App, OAuth app, personal tokensGitHub AppLeast privilege, short-lived tokens, clear audit trailProposed
HostingVercel, Netlify, Cloudflare, self-hostedVercelNative Next.js support, previews, promotion and instant rollback through an APIProposed
Dashboard sign-inBetter Auth, Clerk, Auth0Better Auth with GitHub sign-inSimple, self-hosted, enough for an internal toolProposed
Cheaper AI models per taskSonnet 5.5, Haiku 5.5Not used initiallyAdopt per task only after quality is measuredDeferred
12 · Delivery roadmap

Sixteen weeks, seven phases, each closed by an exit gate

Week numbers count from project start. A dedicated team of three works in parallel. Phases overlap wherever work does not depend on the previous gate: Figma extraction starts before the database is finished, and the DevOps engineer builds the sandbox and hosting integration while generation is being developed. About one week of contingency is held in Phase 6. The plan is re-baselined after the Phase 0 spikes, and any change is agreed with you at a phase gate.

0Weeks 1–2

Discovery and technical decisions

Lead: whole team. AI engineer runs the Figma and model spikes; DevOps engineer runs the GitHub, Vercel and sandbox spikes; full-stack engineer owns requirements and acceptance criteria.

Tasks
  • Approve the decision register
  • Obtain accounts and credentials
  • Spike: Figma extraction on three real files
  • Spike: GitHub App creates a repo and commits
  • Spike: Vercel deploys that commit with protection bypass
  • Spike: offline build and browser test in a sandbox
  • Select 10–15 test designs with the designer
Deliverables
  • Approved stack
  • Spike reports with real measurements
  • Threat model
  • Test design set
  • Signed-off acceptance criteria
Risks
  • Figma seat limits
  • Vercel and GitHub App linkage
  • Account procurement delays
Exit gateAll four spikes pass, or each failure has an approved fallback.
1Weeks 3–5

Project foundation

Lead: full-stack engineer. DevOps engineer sets up CI, environments and the local stack; AI engineer defines the specification and plan contracts.

Tasks
  • Monorepo, shared configuration and CI
  • Shared contracts and error catalogue
  • Database schema and migrations
  • Run state machine, outbox and reconciler
  • Worker with heartbeats and cancellation
  • Dashboard skeleton with sign-in and live timeline
  • Structured logging
Deliverables
  • One command starts the full stack locally
  • Green CI pipeline
  • Committed decision records
Risks
  • Over-building the platform before the pipeline exists; mitigated by a strict timebox
Exit gateA stub run streams live, survives a worker crash, and can be cancelled.
2Weeks 4–7

Figma ingestion and design specification

Lead: AI engineer. Full-stack engineer builds the access check and the specification viewer.

Tasks
  • Link parser and rate-limited Figma client
  • Access validation endpoint
  • Extraction, rendering and asset storage
  • Normalisation, tokens and page detection
  • AI design interpretation
  • Specification viewer in the dashboard
Deliverables
  • Command-line tool that produces a specification from a link
  • Golden tests on recorded designs
Risks
  • Messy real-world files
  • Very large files
  • API limits
Exit gateThree test files produce valid specifications with correct page detection.
3Weeks 7–10

Website generation

Lead: AI engineer. DevOps engineer delivers the pinned template and sandbox build; full-stack engineer adds generation views to the dashboard.

Tasks
  • Pinned starter template and approved package list
  • UI library adapters
  • Token, font and asset generation
  • Site planner with rule checks
  • Per-component code generation with file checks
  • Sandbox build stage
Deliverables
  • Generated projects downloadable from the dashboard
  • Implementation report per run
Risks
  • Variable code quality
  • AI usage per run
Exit gateTwo of three test files build in the sandbox without repair.
4Weeks 10–13

Testing and repair

Lead: AI engineer for repair and calibration, DevOps engineer for the QA harness. Full-stack engineer builds the QA report view.

Tasks
  • Full QA suite in the sandbox
  • Screenshot capture and section comparison
  • QA report view
  • Deterministic fixes, then bounded AI repair
  • Visual threshold calibration
Deliverables
  • QA and repair packages
  • Calibration report
Risks
  • Flaky browser tests
  • Repairs that do not converge
Exit gateQuality gate passes on two of three files and no accepted patch causes a regression.
5Weeks 12–14

GitHub and deployment

Lead: DevOps engineer. Full-stack engineer builds the repository, deployment and release screens.

Tasks
  • GitHub App integration and commits
  • Vercel project and preview deployment
  • Live smoke tests
  • Release gate, promotion and rollback
  • Repository and deployment panels
Deliverables
  • End-to-end runs returning a verified preview URL
Risks
  • Hosting integration behaviour
  • Build differences between sandbox and Vercel
Exit gateA verified preview URL appears in the dashboard with no duplicate publishes.
6Weeks 14–16

Hardening and client demonstration

Lead: DevOps engineer for security and failure drills. AI engineer produces the measured results; full-stack engineer prepares the demo. Includes about one week of contingency.

Tasks
  • Security review and secret scanning
  • Failure drills for every stage
  • Metrics page
  • Runbooks and documentation
  • Demo script and recorded backup
  • Final POC report
Deliverables
  • Final report with measured results and limitations
  • Production roadmap
Risks
  • Late-found issues; mitigated by the drills
Exit gateThe demo script passes twice in a row from a clean environment.

Team and responsibilities

RoleAllocationOwns
Full-stack engineerFull time, weeks 1–16V1 dashboard and user experience; V2 control plane: API, run state machine, database, live progress; release and approval screens; demo build
AI engineerFull time, weeks 1–16V3 design interpretation and specification; V4 site planning and code generation; prompts and evaluation set; V5 repair loop; visual threshold calibration
DevOps engineer with full-stack skillsFull time, weeks 1–16V5 sandbox and browser test harness; V6 GitHub App and Vercel integration; V7 observability, security, CI/CD and environments; backs up worker and API development
DesignerPart timeTest design set, visual calibration reviews
Client approverCheckpointsStack approval, gate reviews, demo acceptance
13 · Supporting plans

Testing, release, operations and governance

Test plan

  • Unit tests for every state transition and rule check
  • Golden tests on recorded Figma files
  • Replayed AI responses for repeatable integration tests
  • Seeded-fault trials for the repair loop
  • Nightly end-to-end runs on real services

Release plan

  • Previews for every successful run
  • Production only through the release gate and approval
  • Same commit for preview and production
  • Health checks after release, instant rollback
  • No automatic promotion during the POC

Observability plan

  • Run timeline and audit log in the database
  • Structured logs tagged with run and stage
  • Usage per run: AI tokens, sandbox minutes, Figma calls
  • Metrics page for durations and pass rates
  • Tracing and alerting planned for production

Security plan

  • Threat model reviewed in Phase 0
  • Credential-free sandboxes with network phases
  • Approved package list and pinned versions
  • Secret scanning of logs, prompts and sandboxes
  • Security checklist before the demo

Version and upgrade plan

  • All tool versions pinned in the starter template
  • Next.js security releases applied within 72 hours
  • Monthly review of framework and library updates
  • Compatibility checks in CI before any upgrade

Governance and communication

  • Weekly demo of working software
  • Decision register updated as choices are approved
  • Exit gate review with the client at each phase end
  • Risks and open questions tracked in one list
14 · Deliverables and acceptance

How we will know the POC succeeded

DeliverableAcceptance criterion
Working platformRuns from documented local setup; the demo passes twice in a row
End-to-end generationA real Figma file with at least three pages becomes a verified preview URL with no manual coding; a second, different file also succeeds
Quality reportsEvery run shows hard and soft results with metrics and screenshots
Repair loopSeeded faults fixed within the attempt limit in at least 80% of trials; no accepted patch causes a regression
GitHub and VercelRepository, commit and preview URL recorded and visible; repeats create no duplicates
RecoveryA worker crash mid-run resumes automatically; cancel stops a run within 30 seconds
ReproducibilityAny run can be reconstructed from stored records: design version, specification, plan, template, model, commit
SecurityNo secrets found in sandboxes, prompts or logs by automated scan
DocumentationArchitecture, decisions, runbooks, demo script and a final report with measured results and limitations
15 · Risks and mitigations

What could stop the POC, and what we will do about it

RiskLikelihoodImpactMitigation
Real designs are inconsistent: absolute positioning, no mobile framesHighHighDiverse test set, clarification flow, measured fidelity instead of promises
Figma API limits block extractionMediumHighDev or Full seat token, caching by design version, batched requests
AI code quality varies and repairs do not convergeMediumHighSmall generation units, strict file checks, deterministic fixes first, bounded repair, regression suite
GitHub and Vercel automation constraintsMediumMediumIntegration spikes in Phase 0 with documented fallbacks
Sandbox escape or secret leakageLowCriticalNo secrets in sandboxes, network phases, hardened isolation
Fast-moving toolchainHighMediumPinned versions, scheduled upgrades, compatibility checks
Usage cost grows on large designsMediumMediumPer-run budgets, prompt caching, usage reporting
Scope creep into backends or CMSMediumMediumExplicit exclusions; placeholders and report entries instead
Visual scores disagree with human judgementMediumMediumSection-level comparison, layout measurements, calibration against reviewers
16 · Assumptions and dependencies

What we are relying on

Assumptions

  • Internal use by trusted staff within one organisation
  • Designs are marketing or content sites built mainly with Figma Auto Layout
  • At least some designs include mobile frames
  • Text and images in designs are final and licensed for use
  • A dedicated team of three engineers for 16 weeks (full-stack, AI, and DevOps with full-stack skills), with part-time design support

Accounts and access needed

  • Figma Dev or Full seat token with read-only scopes
  • 10–15 representative Figma files
  • A GitHub organisation for generated sites, with our GitHub App installed
  • A Vercel Pro team with GitHub integration
  • An Anthropic API account, with approval to process design data
  • Docker-capable development machines
17 · Decisions for approval

Choices we need from you before building

DecisionProposalAlternative
Platform databasePostgreSQLMongoDB
Job engineBullMQ with RedisPostgreSQL-only queue; Temporal later
Default UI libraryshadcn/ui with Tailwind CSSPlain Tailwind; Material UI later
AI provider and modelAnthropic Claude Opus 5.5Cheaper models per task after measurement
Hosting for generated sitesVercelNetlify or Cloudflare through the same interface
Hosted sandboxVercel SandboxSelf-hosted hardened containers
Demo environmentLocal machine or a single VMHosted dashboard with managed services
Data handlingDesign data may be sent to the AI providerRestricted files excluded or a different provider
18 · Demonstration plan

A 25-minute walkthrough on a real design

SegmentTimeWhat you will see
Setup2 minThe dashboard, connected GitHub organisation and Vercel team
Create3 minPaste a Figma link, review the detected pages and routes, keep the defaults
Run5 minThe live timeline, compressed from a full run; the specification and plan opened while it works
Evidence5 minQA report: routes, accessibility, mobile layout, screenshot comparisons and any repair history
Result3 minThe GitHub repository and commit; the preview on desktop and a phone
Control3 minCancel and retry on a second run; promotion to production and a rollback
Limits2 minA design with lower fidelity, and how the warnings explain why
Questions2 minOpen discussion; a recorded full run is ready as a backup
19 · After the POC

The path to production

Keep custom code safe on regeneration

A dedicated branch keeps the last generated output. When a design changes, only the affected pages are regenerated, and git merges them with your developers' edits through a pull request.

Your design systems

Adapters for Material UI or a client's own component library, CMS integration, multilingual sites and blog content.

Stronger operations

Temporal for durable workflows, webhooks instead of polling, more hosting providers, custom domains, tracing and alerting.

Deeper quality

Cross-browser testing, performance budgets, visual hard gates where calibration supports them, and a human review queue.

Team scale

Per-user Figma access, single sign-on, team roles, quotas and cost dashboards.

Application features

Opt-in form backends, sign-in and data, generated only where the design and written requirements justify them.

20 · Glossary

Terms used in this report

Frame
A top-level artboard in Figma. Some frames are pages; others are components, notes or drafts.
Route
A web address within the generated site, such as /pricing.
Design specification
Frame Pilot's structured, versioned description of the design, created before any code is written.
Design tokens
Named values for colours, type sizes, spacing, corner radii and shadows, shared across the site.
Sandbox
A disposable, locked-down environment where generated code is installed, built and tested.
Hard and soft checks
Hard checks must pass before publishing. Soft checks produce warnings that are reported but do not block.
Preview deployment
A live copy of the site at its own URL, used for review before production.
Release gate
The set of conditions, plus human approval, required before production.
Rollback
Pointing the production address back to an earlier known-good deployment, without rebuilding.
Idempotency key
A unique request label that makes a repeated request return the original result instead of doing the work twice.