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.