agentic-dev/docs/product/company-context.md

# Company Context — Veect

_Living strategy doc · Founder OS · last updated 2026-07-10_

## ✅ NAME DECIDED (2026-07-10): **Veect**

Pronounced **VEEKT** (rhymes with _piqued_). Coined vessel — unclaimed sound, clean searches, veect.com + veect.ai confirmed available at decision time. **Brand mark (as shipped):** the lowercase `veect` wordmark closed by a **square ink terminal** ("the vector point") — no pictorial mark; design language = the monochrome ink instrument (see `veect-design-spec-current.md`). Chosen over finalists Weef, Vez, Gesso, Jig, Bezier after an 8-territory, ~150-candidate search with per-name conflict verification.

- Registered/actioned by founder: veect.com, veect.ai. **Still open 🔴:** veect.dev, npm `veect` + org, GitHub org, X handle, EUIPO/USPTO knockout (classes 9/42; assess **Vectr** adjacency — vectr.com, an active vector-graphics editor), counsel pass before incorporating. Entity name suggestion: _Veect Labs d.o.o._

---

## ⚡ PIVOT (2026-07-10): repo-native distribution — **rev 1.2: standalone app, remote-first**

Veect is a **standalone design application** (desktop, bundled runtime — no system Node needed; plus a **Docker image** for team/self-host/CI) that **connects to a repository**: GitHub (device-flow), any git URL, or a local checkout. One `veect.config.json` in the repo points at the component folders (a visual wizard writes it if absent). Each design project auto-creates a **git worktree + branch** (`veect/<slug>`, kept in app-managed workspaces — the user's repo is never touched); data lives in local **SQLite** plus a canonical `design.veect.json` committed on the branch; **Publish** pushes the branch and hands the designer a PR link. The npm-installed-in-repo package (Storybook-style) is a **later distribution** on the same core. Full spec: `veect-technical-spec.md` (rev 1.2).

**Why this is stronger:**

- The **mapping problem dissolves** — the canvas renders the repo's _actual_ components via the host's own toolchain, so exported code imports the real library by construction. The old red-team's #1 gap (engineer's merge bar) is solved structurally. 🟢
- **GTM flips to a Storybook-like bottom-up dev-tool motion** — the developer installs it, then invites the designer in. This sidesteps much of A2 (designers adopting a new canvas) by making the dev the champion.
- Purpose sharpened (founder's words): _bring designers closer to developers so they work on prototypes directly on the codebase, with the components and context the codebase actually holds._

**What it changes / adds:**

- **Riskiest assumption A5 — materially weakened by rev 1.2 🟡:** the standalone app bundles the Node runtime, clones the repo itself, installs dependencies itself, and manages env values in an encrypted local store — the designer no longer needs a dev environment, only **git installed + repo access + (for full-fidelity preview) env values**. Residual friction to validate: getting repo access granted, and apps whose previews need real secrets/backends. GTM note: the designer can now **self-serve** with read access — the developer's moment shifts from "install it for me" to "review my PR," which is a stronger wedge into the team.
- **Competitor frame shifts 🟡:** nearest neighbors are now **Onlook** ("Cursor for designers", edits real local code), **Storybook (+AI)** as the incumbent in-repo component tool, and Subframe. Veect's distinction: _component-registry canvas + project-as-worktree + constrained AI + designer-grade UX_, composing **new** designs from the real system (vs. Onlook editing existing pages; vs. Storybook documenting components rather than composing with them).
- **Business model note 🔴:** this distribution begs **open-core** (OSS/source-available tool → paid team/cloud layer: hosted previews, design sync, AI credits, dashboards — the Storybook→Chromatic analogy). Decide before launch; not blocking the build.
- Superseded from the SaaS PRD: F1 token-file import (tokens now read from the repo), F2 component _mapping_ (components are real by construction), F8 auth/cloud projects. The design brief's UI/UX (canvas, tokens panel, AI ghost layer, refusal, polish) carries over intact.

_Locked with founder: AI compose in v1 (BYO Anthropic key) · full Next.js support (managed `next dev` adapter) · SQLite + JSON-in-branch hybrid persistence._

**Asset status (2026-07-10):** an **interactive editor prototype, landing page, and React 18/TS codebase exist** (`veect-design-spec-current.md` is their spec; React Flow board substrate, zustand store, two-way TSX grammar, responsive view clusters, constrained-AI UX, Polish, history — all built). The remaining product surface is the repo-native layer — connect/publish/environment — specified in `veect-ui-gap-spec.md`.

---

_Status: Phases 1–5 **compressed** at the founder's request to jump to Phase 6. Confidence tags: 🟢 verified · 🟡 reasoned · 🔴 assumed / needs validation._

> Name is decided (see header). Trademark counsel pass remains the one open naming item. 🔴→🟡

---

## 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,
- **Veect 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 Veect-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.