Rodrigo Silveira
Why I created Velloo
On the best teams I've worked with, design was a step ahead of the code. Then coding agents made the code faster. This is why I built Velloo.
One screen. Years of judgement.
I’ve spent many years working on products, and one of the parts I’ve enjoyed most is working with designers.
A good designer brings a narrative along with the visuals: what matters on a screen, where someone’s attention should go, and how each choice helps the person using the product. Behind the direction they present are years of experience and alternatives they’ve already considered. You might see one option, but their judgement contains much more than that.
The best designers I’ve worked with make that thinking accessible. You ask a question, point out a constraint, or explain something about the customer. They listen, challenge an assumption, and refine. You come away understanding both the design and the reasons behind it. The product gets better through that conversation, and so do I: each one deepens my understanding of what we’re building.
At one fast-moving startup, before AI could write much of the code, design was always a step ahead of engineering. When a question came up, our designer already had a direction in mind, and they could sketch an alternative on the spot while we talked it through. By the time we started building, we had agreed on what we were building and why.
That is the experience I want to get back.
When building gets ahead of thinking
AI has given engineers an enormous boost in productivity. You describe a feature, work with an agent, and watch it take shape in minutes. Shipping can be quick and fun. What I enjoy most is being able to focus on what I want to build, with less of my attention spent on how to put it together.
More recently, I worked with a small team of talented engineers and a talented designer, building highly autonomous coding agents. The code moved faster than any design process could keep up with. Instead of staying ahead, our designer ended up reviewing screens that had already landed, and every suggestion became a request to change something that already worked. The engineers were reluctant to rework it, and the designer was left arguing for changes after the fact. Nobody was wrong, and it was demotivating for everyone.
What changed wasn’t talent or care. It was the order. The agent produces a working interface, there’s another feature waiting, and its first proposal becomes the thing that ships. Decisions about hierarchy, flow, and interaction get made along the way, often without anyone stopping to discuss them. Once something works, changing it feels like rework, even when an agent could redo it in minutes.
Make room for the conversation
None of this is a new idea. Designers have explored alternatives, gathered feedback, and refined their work for as long as there have been design tools, and good tools already support it well.
What has changed is where a screen starts. On the teams I’ve worked with, more and more interfaces begin as a prompt in a code editor, often from someone who never opens a design file. When the design step gets skipped, it’s rarely because nobody values it. It’s because it lives somewhere else, and the code is already moving.
I kept coming back to a question:
How could the design conversation happen ahead of the code again, when the code moves this fast?
Velloo is my answer: bring that familiar process to where the work now begins, in the repository and the coding agent the team already uses. You explore a few directions with your agent, compare them side by side, and share them with the team. Comments guide another round. Implementation follows a direction you’ve thought through together.
You could build three versions in code instead, and for small changes you should. But each one pulls in data, state, and routing before anyone has agreed on the direction, and each lives on its own branch or preview. On a canvas, the options sit next to each other, cost little to throw away, and carry comments pinned to the part they’re about.
When you’re working solo, your agent can be a design buddy: proposing alternatives, talking through tradeoffs, and helping you question your first instinct. You still need to judge its suggestions against what you know about your users and the task.
My hope is that repeating this process helps a team understand its product more deeply: developers learn the reasoning behind design choices, designers see technical constraints earlier, and more people can explain how a decision was reached. A tool can’t make time for that conversation or decide who makes the final call. It can make the conversation easier to have.
A real decision
Here’s how I used Velloo on Velloo itself. As the sidebar filled up with boards, I needed to decide how to organize them. I didn’t tell my agent which options to pursue. I asked it to explore the problem, including how other tools solve similar ones, and it came back with seven directions, ranging from tags and filters, to groups drawn as regions on the canvas, to splitting the work across multiple design folders.
Then came the part that needs judgement. I went through the options and rejected a few. Deriving groups from names was too magical: renaming a board would silently move it somewhere else. Projects were retired, because multiple design folders answered the same need.
What helped most were the notes. Because the agent works from the code, each direction came with more than a picture: what it would change in the schema, the MCP tools, and the folder structure, how it could fail, and what it would cost to build. I could weigh the impact of each option before any of it was implemented. Groups of boards and multiple design folders shipped.
Close to the product you’re building
Keeping Velloo local and ready for agents is a deliberate choice. The design files live beside your code, and you use the agent you already work with. The canvas can render supported components directly from your repository, with your theme. Your agent can read the surrounding code to work out how a feature would connect to the app. You can review a direction before wiring up its behaviour and data.
Your designs can also live in Git alongside the code. An experiment gets its own branch. A commit captures a revision, and its message can explain why you changed course. You can revisit an earlier direction, compare what changed, and follow how the design evolved. The history becomes part of the product’s memory.
Velloo’s local canvas is free. When you’re ready to share, the free cloud plan lets you invite as many reviewers as you want to join the conversation.
An experience, shaped together
A product is more than working code and a collection of screens. The experience comes from how the details fit together. For example:
- Consistency: familiar controls and patterns, so each screen builds on what someone has already learned.
- Voice: labels, confirmations, and error messages that sound like the same product and help people understand what happens next.
- Brand: typography, colour, and visual choices that make the interface recognizably yours.
- Flow: a clear path through a task, from the first encounter to the moment someone gets value.
These choices add up across the product. A screen can work perfectly on its own and still feel out of place in the experience around it.
No one person holds all of that. Designers bring the judgement to see how the pieces fit together. Product managers know which problems matter most. Researchers and support teams hear from customers every day. Marketing knows the voice and the brand. Engineers know what the system can and can’t do. The experience is better when those perspectives arrive while the direction is still open, not after the code has landed.
I created Velloo to make room for them. AI gives us the speed to explore. When people across the organization can see the options and join the conversation early, we bring more perspectives to what we’re building and share responsibility for how it feels to use.
Try Velloo with a feature you’re thinking about building. Explore a few directions with your agent, refine the one you like, and bring someone else into the conversation when you’re ready.