COMPARE · GENERATED VS DESIGNED
v0 or a design studio — where generated UI stops working
v0 and similar tools generate working UI components from a prompt, which is faster than any design process for standard patterns. They break down on the parts that are specific to your product: unusual states, multi-role flows, and the rules that keep the twentieth screen consistent with the first. Use generated components inside a designed system.
WHAT IT IS GOOD AT
Standard patterns, instantly, in code your engineers can use.
For anything the web has already solved a thousand times — a settings page, a data table, a signup form, a pricing section — a generator gets you a working, reasonable version faster than any design process. Refusing to use that is not craft, it is overhead.
WHERE IT BREAKS
On everything specific to your product, which is what you are actually selling.
THE STATES PROBLEM
Ask for a dashboard and you get the version where the data is present, complete and correct. Real products spend a surprising share of their life in the other states: the account with no data yet, the request still running, the answer that came back partial, the model that was confident and wrong. Those states are where users decide whether the product is trustworthy, and they are almost never in the prompt.
The second failure is drift. Every generation is an independent answer, so screen ten does not necessarily agree with screen one about spacing, hierarchy, or what a primary action looks like. Nothing is broken; the product just does not feel like one thing. That is a system problem, and systems are the part a generator has no way to hold.
For AI products specifically there is a third: probabilistic output needs interface work that has no standard pattern to copy. How confident is this. Where did it come from. How do I correct it. What is it doing while it thinks. There is no canonical component for any of that yet, which is exactly why it is worth designing.
HOW TO USE BOTH
The studio sets the system. The generator fills it in.
This is how we work in practice. Define the tokens, the components, the spacing scale and the interaction rules, then let generated code build inside that. The generator stops producing a fresh opinion every time and starts producing consistent output, and your engineers keep the speed advantage that made the tool worth using.
Vryfi Now is the shape of the work that does not generate: a mobile app for payment disputes in private communities, with a management portal on the other side of it, different roles seeing different truths, and a flow whose whole job is making a disagreement resolvable. There is no prompt for that, because the hard part is deciding what the product should do, not rendering it.
THE HONEST LINE
Generate the parts that are the same as everyone's. Design the parts that are not.
If a screen exists in a thousand other products, generate it and move on. If a screen is where your product is different from every alternative — the core loop, the moment the value lands, the point where trust is won or lost — that is the one worth designing, and it is usually a small fraction of the total surface.
QUESTIONS
Can v0 replace a product designer?
For standard patterns — a settings page, a table, a form, a pricing section — it produces usable output faster than a designer can open Figma. It cannot decide what your product should do when the model is uncertain, when a user has three roles, or when the data is partial. That is where product design actually lives.
What breaks when you build a whole product this way?
Consistency, mostly. Each generation is a fresh answer, so the tenth screen does not necessarily agree with the first about spacing, hierarchy or what a primary action looks like. The product ends up as a collection of reasonable screens that do not feel like one thing.
Is the output good enough to ship?
Often yes, for internal tools, admin surfaces and early versions. For the surface you sell on, it is a starting point. The gap is rarely visual polish — it is the states nobody prompted for: empty, loading, partial, failed, and the ones that only appear when something goes wrong.
How do you work alongside these tools?
We use them ourselves. The useful division is that the studio sets the system — tokens, components, spacing, interaction rules — and generated code fills it in. A system makes generated output consistent instead of accidental.