v0 is a generator. The output is a starting kit, not a finished page. Here is the workflow that has worked for me over 24 prototypes[1].
Step 1: prompt for structure, not content
Bad prompt: "Build me a landing page for my SaaS."
Good prompt: "Hero section with title, subtitle, primary CTA. Three-column feature row. Pricing table with two tiers. FAQ accordion with 5 items. Use shadcn primitives, dark theme."
The output of the second prompt is structurally what I would have built anyway. The output of the first is a guess at content I will throw away.
Step 2: copy to repo, do not "Add to project"
The Vercel "Add to project" button works but couples your repo to v0's component structure. I copy the JSX into my repo by hand and adapt to my design tokens immediately.
Step 3: throw away the data
v0 hardcodes features = [...] arrays inline. I extract these to my CMS or content layer immediately. If I leave them inline I never come back to fix it.
Step 4: replace styling with my system
v0 uses default shadcn tokens. My projects use custom tokens (typically Geist + Playfair Display, custom primary, custom radii). I run a quick find-and-replace and adapt the typography immediately, before adding any logic.
Step 5: keep what works
v0 produces good copies of well-known patterns. Pricing tables, hero sections, faq accordions, settings pages. Keep the structure.
v0 produces poor copies of unusual patterns. Animated heroes, custom marquees, anything bespoke. Throw away.
Step 6: never let v0 add features once you start coding
Once I have started building, v0 is no longer the right tool. The codebase has accumulated context (state, hooks, components) that v0 does not see. Asking v0 to "add a feature" to my code produces broken output 60 percent of the time.
For changes after the initial scaffold, Cursor or Claude Code is the right tool.
The split
v0 for the first 30 minutes. Cursor or Claude Code thereafter. The handoff is when I have a static page and need to wire data fetching.
About the data
A note on what the numbers in this post represent so you can read them with the right confidence:
- "My own bench" rows are personal measurements on my own hardware. They are honest about my setup and reproducible there, but they should not be treated as universal benchmark scores.
- Benchmark numbers attributed to public sources (Geekbench Browser, DXOMARK, NotebookCheck, FIA timing) are illustrative, the trend is what matters, not the third decimal place. Cross-check against the source for anything you would act on financially.
- Client outcomes and ROI percentages in business-focused posts are anonymised composites drawn from my own consulting work. Real numbers, real direction, sanitised so individual clients are not identifiable.
- Foldable crease-depth and similar engineering measurements are estimates pulled from teardown reports and reviewer claims; manufacturers do not publish these directly.
- Forecasts and "what I bet" lines are exactly that, opinions, not predictions with a track record yet.
If you spot a number that contradicts a source you trust, tell me, I would rather correct it than be the chart that was off by 6 percent and pretended otherwise.