agentic-dev/docs/product/reference/project/uploads/company-context.md

Company Context — "Weave" (working name)

Living strategy doc · Founder OS · last updated 2026-07-09 Status: Phases 1–5 compressed at the founder's request to jump to Phase 6. Confidence tags: 🟢 verified · 🟡 reasoned · 🔴 assumed / needs validation.

Working name only. "Weave" is a placeholder so the docs read cleanly — not a naming decision. Real naming/trademark is a separate exercise. 🔴

---

One-liner

A design-system-native canvas that turns your own tokens and components into real, production-ready React, held to a craft standard (Impeccable) so output is on-brand and genuinely well-designed — so what a designer composes is exactly what ships.

Problem

Product designers who already have a design system still can't ship on-brand UI without waiting on engineering. Today's AI design/code tools (v0, Lovable, Bolt, Figma Make) re-invent generic UI instead of using the team's own components and tokens — so the output is off-brand and thrown away, and the design→code handoff stays lossy.

• 🟢 92% of designers and 91% of developers say the handoff process needs improvement (Figma, State of the Designer).
• 🟢 Figma Make users report it "won't use my library components" / "created new ones that just looked like mine"; v0 "treats the Figma file as a screenshot" (Figma forum; user teardowns).
• 🟢 The market has already conceded the pain — Bolt, Lovable and Figma all bolted on "use your design system" features in 2025 because generic output was the #1 designer complaint.

Beachhead ICP

Product/UI designers and design-system / design-engineer leads at startups & scale-ups (~10–200 people) that already have a design system (tokens + component library) and ship a React web product. 🟡

• User (feels pain): product designer · design-system designer · design engineer.
• Champion: Head of Design / Design Systems lead. 🟡
• Economic buyer: design leadership budget; escalates to VP/Eng at team tier. 🟡
• Veto: Engineering ("will the emitted code meet our repo standards?") and Security at enterprise. 🟢

Top Jobs-to-be-Done (from discovery research)

1. When I finish a design, I want the built UI to match it exactly without policing every pixel, so I can stop redlining.
2. When our design system changes, I want Figma and code components to stay in lockstep, so "the library" means one thing everywhere.
3. When I need a screen shipped, I want to produce it myself without an eng sprint slot, so I can move at the speed of the idea.
4. When I use AI to generate UI, I want it built from my components/tokens (not a generic theme), so I get on-brand output I don't throw away.

Wedge / Positioning (April Dunford frame)

• For product designers who have a design system but can't ship on-brand code without engineering,
• Weave is a design-system-native canvas that emits real, production React from your own tokens + components,
• unlike v0 / Lovable / Bolt / Figma Make, which are developer/prompt-first and generate generic, throwaway UI,
• so that what you design is what gets built — on-brand, high-craft, with zero translation loss.
• Category: "design-system-native design-to-code" — a wedge inside the crowded AI-builder space. 🟡

Two things deepen the wedge (added after review):

• Real-component mapping — export emits the team's real coded components (their import paths + prop names), not Weave-internal clones. Without this the output never clears the engineer's merge bar and the wedge collapses to "v0 with theming." 🟢 (this was the single biggest gap the red-team found)
• Craft layer (Impeccable) — beyond "constrained to your system," a Polish pass holds output to a craft ruleset (impeccable.style — an open-source anti-"AI-slop" design language for AI harnesses). On-brand and high-craft is a sharper position than either alone. 🟡

Why now

AI codegen is finally good enough for constrained composition; design-token standardization (W3C DTCG) is maturing; "design engineering" is rising as a role; Figma Dev Mode's per-seat pricing backlash has opened a door. 🟡

Competitive frame (from existing knowledge — deep teardown deferred)

Cluster	Players	Why they don't own the wedge
Prompt/dev-first app builders	v0, Lovable, Bolt	Fast but generic output; prompt-first not canvas-first; not BYO-design-system-first
Visual design-to-code	Subframe (closest), Builder.io Fusion, Anima, Locofy	Subframe is strong but leans "design in browser → code"; others are dev-first imports or Figma-plugin exporters with fidelity issues
Site builders	Framer, Webflow	Own proprietary runtime; you don't get your React components/code
Incumbent	Figma (Dev Mode, Make)	Enormous stickiness, but generic AI output and a handoff "tax"; not designer-owned code from your system

White space (the bet): a designer-first canvas where a bring-your-own design system is the source of truth and AI is constrained to it. 🟡 (Subframe is the nearest competitor; a real teardown is still owed to harden the "unowned" claim — see 🔴 A4.)

North Star Metric

Weekly shipped screens — screens whose code is exported and actually used, per active designer. No repo integration yet, so proxy it via an explicit "mark as shipped" + design-partner check-ins. 🟡

• Activation: first screen composed from the user's own tokens + components and exported. 🟡
• Trust bar (primary, engineer-judged): real PRs at design partners — merge rate + % LOC changed pre-merge. The right judge is the engineer, not the designer's self-report. 🟢
• Wedge-usage guardrail: % of exported screens composed majority from the user's mapped/real components (not stock base kit) — so we can't "pass" by validating a re-themed generic kit. 🟡

Business model (compressed — full Phase 5 deferred)

Per-seat SaaS for designers with a usage component on AI compose; land bottom-up with individual designers, expand to design teams. Not yet modeled. 🔴

---

Validation gate status (Phase 1) — NOT formally cleared

The pain is real and well-sourced 🟢, but the core belief rests on unvalidated assumptions. Per Founder OS discipline, the MVP in the PRD is scoped as the cheapest way to test the core bet, not a green-lit build. Run the validation experiment (see PRD §Risks/Validation) in parallel with any build.

Riskiest assumptions to validate

• 🔴 A1 — Designers want to compose/own real code. Many want the outcome (their design shipped faithfully, fast), not to own a codebase. Evidence is genuinely mixed; some designers report AI codegen is slower than just designing.
• 🔴 A2 — Designers will adopt a new canvas. Figma stickiness is structural (libraries, network effects, org process); real-world switching is usually additive / per-phase, not a replacement.
• 🔴 A3 — The bottleneck is tooling, not governance. Practitioners repeatedly say design-system drift/sync is a people-and-process problem a tool alone won't fix.
• 🔴 A4 — "BYO design system → real code" is genuinely unowned. Competitive teardown was deferred this pass; Subframe is close. Harden before fundraising claims.

Validation gate (sequenced, with kill criteria — run before/at the start of build)

1. Concierge real-PRs (primary): hand-build 5 partners' screens from their own systems and open real PRs against their repos. Pass ≥3/5 merged with <10% LOC changed; kill/rethink if <2/5 or reviews are structural. Tests A1 and the trust bar with the correct judge, with zero product code.
2. Clickable-mock task test: 5 designers complete the core task on a Figma prototype of the editor. Pass ≥4/5 unaided. Tests A2 (will they adopt a new canvas) before the canvas is built.
3. Fake-door demo vs. a v0-style generic control: pass waitlist conversion ≥2× control.
4. Competitor teardown (Subframe et al. — owed from Phase 2) to harden A4. No code needed.
5. 10 problem interviews with design-system leads probing A1 and A3.

Founder OS discipline: only the token-engine + shared-runtime spike should run concurrently with these. "Build in parallel with validation" is how the gate gets quietly bypassed — the red-team flagged exactly this.