Varve is a local-first design suite for vector, layout, typography, motion, prototyping, print, photo, and email — one application, no subscription, no cloud account. I designed the product and I ship the editor in code.
Source-available — read the code on GitHub or download the beta from varve.studio. Licensed FSL-1.1-MIT (not OSI-approved open source; each release converts to MIT two years after it ships).
Current status (v0.5.0, 9 Oct 2026) — Public beta. Six task workspaces. Linux, macOS (Apple Silicon), and Windows installers. An experimental browser demo at varve.studio/try. 25 GitHub stars (Oct 2026). Installers are unsigned. The
.varveformat can still change.
Problem
I kept hitting two walls that no existing tool solved together.
Fragmentation. A vector illustration lives in one app. The page lives in another. Motion lives in a third. Print export lives in a fourth. Each hop costs design intent: the relationship between a type hierarchy and the illustration it sits on, the constraint between a print page and the screen composition it came from.
The platform. I work on Linux. Figma is a browser. Illustrator, InDesign, and After Effects do not ship native Linux builds. Inkscape, GIMP, and Krita are strong at their jobs and do not cover the full multi-discipline workflow.
The core insight: The problem is not that any single discipline is unserved. The problem is that creative work crosses disciplines constantly — and if you are on Linux, the tools themselves often do not reach you.
Constraints
These were product constraints, not just engineering ones:
- Local-first, no account. Core editing works offline. Files live on disk as
.varve. Network is opt-in (model downloads, font/icon search, update checks). - Linux is first-class, not a port. WebKitGTK does not give you WebGPU for free. The renderer has to work today on the platform I develop on.
- One document, six jobs. Design, Print, Draw, Photo, Motion, and Email share a scene — they cannot be six apps that happen to share a window.
- I am a solo founder. Scope, interface, and what ships are my calls. I build with AI coding assistants and I am accountable for every change. That is documented in how Varve is built.
- Honest beta. Interfaces and the document schema can still change. Signing is not done yet. The browser demo is bounded; the full product is the desktop app.
Design decisions
One scene graph, six workspaces
v0.5.0 makes that opinion visible in the chrome: six task workspaces — Design, Print, Draw, Photo, Motion, Email — sharing one document. Logo tools stay in Design; code export is available from every workspace.
Print workspace over the same poster document — Design, Print, Draw, Photo, Motion, and Email share the scene.
Shared workflows stay on the document when the workspace changes — not a separate file per discipline.
Email workspace over the same poster — template settings, preview, and HTML output share the scene.
IR-replay instead of pixel-push
The native Rust engine and the Tauri webview live in different runtimes. A native wgpu surface cannot sit inside the webview DOM.
Local-first as a product decision
From token to code
The design system has to work in two places at once: the editor chrome and the document canvas. A swatch in the inspector and the fill on a shape need the same source of truth.
@varve/tokens implements DTCG (W3C Design Tokens Format). @varve/ui turns those tokens into CSS and APG-pattern React components. v0.5.0 also ships manual token sync: import and re-import token sources, review mapping diagnostics — no automatic write-back, no Git watcher.
That is the path a control actually takes:
- Token (DTCG) — a color, space, or type token in the design-system source.
- CSS custom property — emitted by
@varve/ui(OKLCH, light / dark / high-contrast). - React component — inspector control, button, or panel, following APG patterns.
- Scene application — the same token value can be applied to a node fill, so the chrome and the artwork do not drift.
// Schematic of the published pipeline — DTCG in, CSS + React out.
// Tokens live in @varve/tokens; components live in @varve/ui.
const color = tokens.color.bg.panel; // DTCG → typed token
// CSS: --color-bg-panel: oklch(...);
<button className="bg-[var(--color-bg-panel)]">Export</button>
What this means for the product: the design system is not a separate deliverable. It is the living surface of the application. Token import is a designer workflow, not a build-only step.
A canvas fill bound to a token alias — the inspector and the artwork share one DTCG value.
Export from the same tokens: CSS, React, and file formats from the live document.
Code tab on the same headline: display-headline.tsx and display-headline.module.css generated from the live selection.
Architecture
From the public README:
Desktop shell (Tauri)
↓
Editor / scene model (@varve/editor, @varve/scene)
↓
Engine abstraction (@varve/engine — Tauri / WASM / in-memory)
↓
Rust native ⇄ WASM (crates/varve-core, varve-layout, varve-effects, …)
↓
Render IR
↓
Canvas2D (default) / WebGPU and WebGL2 (experimental, opt-in)
| Package | Purpose |
|---|---|
@varve/ui | Design system tokens, APG-pattern components |
@varve/editor | Editor shell, canvas, layers, inspector, tools |
@varve/engine | WASM / native / stub facade with IR-replay |
@varve/scene | Immutable document model with ops |
@varve/codegen | SVG, React, Svelte, Vue, Flutter, SwiftUI, email HTML, and more |
@varve/platform | Tauri / web / memory |
The native desktop app is the full product. The browser build at /try/ runs the editor on the WASM engine with honest capability messaging — print, inference, and other desktop-only paths are not implied by the demo.
v0.5.0 widened what those workspaces can hold: illustration and tablet controls, comic lettering, photo retouch, Shape Builder, reusable patterns, presentation decks, local Wasm plugins, and consent-first desktop updates. Motion remains in public beta. RAW development and model-based photo features have documented limits.
Testing
Nothing is trusted just because a tool wrote it. How Varve is built states the 0.5.0 checkpoint:
- 1,903 browser test cases against the real canvas
- 1,909 unit test files
- Visual comparisons and a WebAssembly build
- Impact-aware CI on every push; full suite weekly
- Releases built in CI from the tagged commit, then checked on Linux, Windows, and macOS (upgrade, save and reopen, export)
- SHA-256 checksums, SBOMs, and build provenance on every release
- Installers are not code-signed yet
The distinction that matters: "The function passed" is not the same as "the editor visibly behaved correctly."
How I build (and how AI is involved)
I make Varve on my own. I decide what it should be, design it, direct the work, review and test it, and I am responsible for every change that ships. AI coding assistants — Claude Code, Codex, Cursor, Devin, opencode, Windsurf — draft a large share of the TypeScript editor, the Rust engine, the desktop shell, tests, scripts, and docs. I review, rework, and test on my Linux machine (CachyOS).
That disclosure lives in the repo: docs/how-varve-is-built.md. Commits do not carry AI co-author tags; the page is the disclosure instead.
Varve's product AI is separate: optional, on-device (background removal, enhancement, object selection, generative edit). There is no Varve-hosted inference service. v0.5.0 does not generate images from a text prompt.
What didn't work
Early releases taught the same lesson as the architecture: release engineering is a product surface. v0.1.0 could not publish. A static eval import painted a white screen in the WebView. Bundled WebKit/GTK broke on newer Linux hosts. I shipped v0.5.0 only after the tagged candidate passed release and publication gates.
Breadth still taxes consistency. Each new workspace touches every existing one. That tension is not solved; the workspace switcher is how I keep it usable.
What's next
Shipped in v0.5.0
- Six task workspaces on one document
- React/TypeScript editor on a Rust/WASM engine
- DTCG tokens and manual token sync
- Local-first desktop builds (Linux, macOS, Windows)
- Bounded browser demo at
/try/
Working but evolving
- WebGPU / WebGL2 (opt-in, hardware-dependent)
- Motion (public beta)
- Photo / RAW and model-assisted workflows (documented limits)
- Code export and local Wasm plugins
Not yet solved
- Real-time collaboration (UI scaffolding only)
- Platform code signing / notarization
- Production-stable
.varveformat - Automatic token write-back
- Full browser/WASM product (the demo is not that)
Explore the project: varve.studio · github.com/K-Arthur/varve (FSL-1.1-MIT, source-available).
Related work: OpenCode Harness — a deterministic AI development interface, where state correctness is the design problem. Moremi AI — the clinical product-design work that came before Varve.