Give your coding agent a place to design.

Keep your design tool. A drawing tool is where an interface gets invented: brand, illustration, motion, and the first version of a system that has no components yet. Velloo is the other half of the job, the part that happens once a product already has a framework and a component library. It builds screens out of those components, in the repo, so the work can be reviewed and implemented without being redrawn. Most teams will use both, and they rarely want the same thing on the same day.

Those products take a prompt and hand back a working interface, and they are good at it. Velloo is organized around the step where a team looks at what came back and decides. The agent builds into a folder in your own repo, using your own components, and can keep several screens side by side on one canvas. The difference shows up when you want a second option next to the first, or when someone outside the repo has to review what the agent produced.

It can, and it should. Seeing is solved and free. The gap is everything a screenshot does not carry: a picture does not tell the agent that the element is a <Card> from your library, that the border came from a token, that a prop change should reach every frame using that screen, or how to write the change back into the repo. Velloo hands the agent the structure under the pixels, plus somewhere to put the result. The screenshot is the part you already had.

No. The problem it addresses is that interfaces now get drafted in the repo, often before anyone schedules a review, which tends to route around design rather than replace it. A published board is a way back in: real screens, in the real theme, with comments pinned to specific nodes that return to the developer's canvas. Deciding what is right, and knowing what has to stay consistent across the product, is still the work, and it is still yours.

The local canvas and MCP tools are free, open source under Apache-2.0, and run with no account. That is the complete local product, not a trial. Velloo Cloud is the opt-in half: published boards, comments that return to your canvas, team workspaces, and hosted asset generation. The free plan covers three published boards, and paid plans add shared workspaces where reviewers and guests take no paid seat. See the pricing page for the details.

Most likely yes, even if it isn't one Velloo adapts. Adapters and styling channels cover shadcn/ui with Tailwind className, Material UI and Chakra with sx, and Ant Design and no-library React with inline styles. Beyond those, your app's own components — a package it depends on like Mantine, a private design system, or your own components directory — are found by reading what your app renders and drawn on the canvas from your own installed copy, then emitted with their exact imports. Velloo checks each component and reports how it actually rendered rather than quietly approximating it. How your own components are rendered.

Anyone with a link. A published board opens in a browser with no install and no repo access, which is how a designer, a product manager or a client sees the work. Looking costs nothing and needs no account. Your organization always comments; a guest you invite to a board comments from their personal link, and anyone else can comment when you turn on public commenting. Comments pin to a node and travel back to the local canvas for the agent to act on. Reviewers and guests never take up paid seats.

It can, if the directions are cosmetic variations with no decision behind them. The useful version gives each direction a distinct premise, holds the same constraints across all of them, and judges them against a stated bar. Velloo makes the alternatives visible and comparable. It does not supply the judgment that makes them worth comparing.

For checking a single screen, a screenshot, a diff and a dev server are enough, and you already have them. Comparing is different: it means moving your eyes between the options, at the same viewport and in the same theme, without holding the last one in memory. That is a spatial problem, which is why the directions sit side by side on a canvas instead of in a sequence of messages.

No. Plenty of screens do not deserve it, and nothing in the tool insists. Velloo works as a component-structured canvas for one screen: build it, check it in both themes, compare it against the running app, implement it. The alternatives are there for the decisions that are actually worth a second look.

They live in a folder as ordinary JSON, one readable component tree per screen, in your app repo or another folder you choose. They diff in Git, review in a PR, and revert like anything else. If you stop using Velloo, the code you shipped is just your code, and the design files are just files you own. There's nothing to export and nothing to get out of.

No. Velloo is an MCP server, so it plugs into the agent you already use: Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode, Windsurf. You keep your editor, your model and your prompts. The agent gains a visual surface to put the work on, and a way to lay out more than one version of it.

The local loop runs on your machine, is telemetry-free, and works with no account. The CLI makes one anonymous update check against the public npm release version at most once a day; it sends no project or account data, and VELLOO_DISABLE_UPDATE_CHECK=1 disables it. Publishing, comments, hosted asset generation, and other Cloud features are opt-in. See the docs for exactly what each one transmits.

Velloo emits the chosen screen as structured, framework-native intermediate output, not a paste-ready production file. Your agent turns that into real application code, adding imports, routing, state, data, and handlers in your project's conventions. The result shows up in your diff and goes through the review process you already use.