Hello all,
I would not consider myself a prompting expert, but I’m somewhat of a veteran using v0. I have been using it since launch day for side projects, have been one of the first subscribers (remember the white page that generates 3 variants for your prompt?), and now I’m using it almost daily to ship production code at my current job.
I’ve seen complaints about insane token usage of user requests. I honestly cannot reproduce this and my usual token usage is below the mentioned median of $0.08 per prompt. I’m still getting a ton of use out of v0 without exceeding my monthly token allocation.
So I guess there would be some value in sharing my workflow and experience with v0, to help others get the best experience possible.
First of all: I optimized our codebase to align with the “cool kids tech stack”—Next.js, Tailwind, shadcn/ui, lucide icons. This way I can usually just copy-paste v0 results and do not have to give explicit input about what frameworks/tools to use.
We work in a medium-sized fullstack Next.js codebase building a data-heavy B2B SaaS product.
A developer’s v0 veteran guide
Know v0’s limits
The more complex a component gets, the harder it will be to get it correct with v0. From my experience, v0 is at the level of a junior to mid-level engineer that requires a lot of support. If you have specific solutions for complex problems in mind, share them with v0. Use another v0 chat or ChatGPT to make your instructions digestible.
If stuff gets really complex or involves deep knowledge of specific libraries or APIs, don’t expect v0 to know them. Let v0 build the boilerplate, leave out the complex parts, and build it yourself. Once you have working code, v0 can usually help to improve it, but make sure it doesn’t break the functionality.
It is just not a reasonable assumption that v0 can do everything. You will spend dozens of iterations with no result on this, so learn its limits.
Keep the context as small as possible
Imagine you’re being asked to jump into a new 1M LOC codebase and to fix the button in the “A module”. Guess what, it will take some time for you to find what exactly needs to be fixed and if this could have implications on any other part of the app. Isolate the problem and mock the surroundings. This helps to keep focus on the problem and doesn’t need millions of tokens to iterate.
Honestly, at the moment, for everything exceeding the size of a small 2–3 pages project, I would not recommend working on the whole project with v0. Maybe this will get better in the future, but it’s probably a non-trivial problem to solve.
Use the right model
v0-lg is significantly more expensive than md. Use it to plan out more complex tasks without generating code. Ask it to generate an implementation plan without implementing any code. Then use md or sm (once it’s released) to implement it. I haven’t done this yet, but this was mentioned in the chat and seems reasonable.
Use case 1: Creating a new component
- Start a new chat with no project, think about a basic version of the required component. Specify the data objects that will go into the component as detailed as possible. Use another v0 chat or ChatGPT to paste in table definitions and ask for type definitions.
- Ask v0 to define or generate matching mock data in the page and then pass them into the component. This has worked sufficiently well most of the time and could even generate data that makes a chart interesting enough to show some edge cases.
- Iterate on the component in v0. Ask for changes and improvements. Revert to an earlier version as soon as possible if you see v0 taking wrong turns. If your prompts are not leading in the right direction, try to improve your prompt with AI.
- Take the component into your codebase and wire it up.
Use case 2: Improve / Fix an existing component
- Upload or paste only relevant files. Tell v0 to render this component in an example and to mock data.
- Be specific with bug reports. What specifically is not working? What is the desired state? “Fix X, it’s not working” can work but is highly uncertain.
- Ask v0 to keep the component’s signature compatible with the original so you can drop-in replace the fixed component. This usually requires that your components are structured maintainably—if every component is full of side effects, the mocking will be harder.
Use case 3: Solving a problem
- Sometimes I see unexpected behavior in React or Next.js and want to understand where my mental model is wrong.
- Ask v0 to create a reproduction of a problem by describing what you want to do. Practical example: “Create a RSC that has a color select. The select value is stored as search params. Render example components using that color.” Next prompt: “In my codebase I’m experiencing lag in between changing the select and the URL being updated. What could be the reason for this?”
- Ask v0 to explore different reasons; it will add them to the reproduction example. Study the code of a reproduction where it works and implement the learnings into your codebase—either manually or by starting a new v0 chat and specifically stating the solution you want and the component that needs to be changed.
. Doing more costs more. Exponentially so.
.