Give your coding agent a place to design.

The practice isn't new, and Velloo doesn't claim to have invented it. Designers have explored directions, gathered feedback, and refined their work for as long as there have been design tools. What changed is where a screen starts: more and more interfaces begin as a prompt in a code editor, often from someone who never opens a design file, and the design step gets skipped because it lives somewhere else. Velloo brings that familiar process to the repository and the coding agent the team already uses, so the conversation can happen before the code lands instead of after.

Keep your design tool. A drawing tool is for freeform work: brand, illustration, motion, anything that isn't made of components. Velloo works in real components from the first screen, whether they come from an app you already have or from a library you pick for a product that doesn't exist yet. It builds screens out of them, in a folder you own, 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.

A step before the code, in the same session. On its own, Claude Code takes a prompt to a working screen: one version, wired to data and routing, that nobody else weighs in on until it is built. For a small change that is the right path. Velloo is an MCP server, so the same agent can first lay out a few directions on a canvas, built from your components and theme, with desktop and mobile, light and dark, side by side. Because it is still reading your codebase, it can pin a note to each direction saying what it would take to build, such as a database schema change. Teammates comment on a published board from a link, the agent works through their comments, and then it implements the direction you chose.

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. Velloo gives your judgement more room in a process where agents can draft interfaces quickly. Define the components, standards, and design thinking that guide the agent, then compare directions and refine them with the team. Published boards let you review real screens in the product's theme and pin feedback to specific nodes. You can propose directions before anything lands, instead of reviewing screens that already shipped, and keep the experience consistent as it evolves.

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 with unlimited reviewers and guests; paid plans add members who publish together. Reviewers and guests never take a 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.

Yes. The HTML + htmx provider works with server-rendered templates and plain HTML sites. Velloo uses your app's CSS and stores copies of its stylesheets and assets with the design, so the canvas can be reviewed without the app running. It keeps real hx-* attributes for native HTML emission; the canvas shows static states and your app supplies the handlers. Design an HTML or htmx app.

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.

You can, and for small changes you should. The cost shows up before anyone has agreed on a direction: each version pulls in data, state, and routing, and lives on its own branch or preview, so comparing means switching between tabs. Once a version works, it also gets harder to argue with, and changing it starts to feel like rework. On the canvas, the directions sit side by side at the same viewport, cost little to throw away, and carry comments pinned to the component they are about. The code comes after the choice.

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.