About four months ago, I wrote My experience developing a full stack app with v0, a brain dump of things that went great and those that didn’t. A lot has changed since then. We now have three models, design mode, marketplace integrations, a stable GitHub integration, and, obviously, the new pricing model.
Project
This time, I started with an idea: an app to track weekly goals that my girlfriend and I set together. The main idea was to keep motivation high and accountability for ourselves.
I’ve added the chat and live application at the end of this post. You can review them as you read the post, but I highly recommend reading the post first to understand the nuances.
My process
I started with a very basic prompt using the medium model.
Version 1
Create an application where users can add weekly goals and check them off as they finish, showing a progress bar for each user for this week.
It gave me a good start, but v0 can’t read my mind. So, it didn’t fit the image I had in my mind. So, I followed my next iteration with a more descriptive prompt.
Version 2
Nice. If there are two users then their should be two user cards with their goals along with the check boxes. We don't need the top select user pop up.
Now, this is what I’m talking about, precisely what I had in mind for my first app version.
From there onwards, I moved to the small model because I wanted to try it out. And let me tell you, it didn’t let me down.
I followed the approach I used as an engineer: break the task into small chunks, small todos, and build in that order. This approach keeps v0 focused on the single task (just like us humans) and, in my experience, made the development much easier because even if the output was wrong, it didn’t change 20 files at once, it made small changes from which going back wasn’t that difficult. Here’s an example prompt:
Use optimistic UI and loaders to improve the perceived performance.
I needed to use some persistent storage for the goals, my first intuition was to use Upstash, and v0 built it for me. However, when I reviewed the code, I realized that using Upstash wouldn’t be the best data model for this application. It was easy to move on with Supabase, and I was able to do it with a few clicks and the following prompt:
Let's use supabase for this so we normalize the data.
This small prompt v0 created the whole data model and the migrations. Unlike when I had to manage all this myself, v0 gave me the options to do all this from the chat itself. I confirmed it right after, and it worked. 
It wasn’t all roses, though. During this transition, I faced:
- Type errors and had to verify that column names and types are matching, and then instructed v0 to fix those issues for me.
- v0 once went on to edit the todos UI and removed the increment/decrement feature.
- The infamous
The file "./supabase-actions" cannot be found. Make sure the file exists.error. This one took me some time, as prompting didn’t help. I had to manually sift through the files and see where the import went wrong. It was because this file was imported and exported from another actions file. I used the search feature with CMD+F in the files to quickly search for it.
It didn’t take more than two prompts to fix any of these issues because I was moving one step at a time, so I could notice and fix them immediately. You can find other examples and the prompts I used to fix them in the chat.
Design mode is a lifesaver
This was my first time using this feature and it deserves a section of it’s own. I realized it’s value after the application had started to mature. Because as the app grows you don’t want to bother the v0 models with minor UI/content tweaks with prompting. I found the design mode extremely useful for text content editing, deleting UI elements, updating font sizes, and elements spacing.
The design mode gives immediate previews into the change and doesn’t cost any tokens as well. I highly recommend using it for all UI edits I listed above.
Caveats and ways to get around them
- Narrowing focus with file tagging: As the project gets bigger, in some cases, v0 might edit files other than what you asked for. You can use
@FILE_NAMEto restrict edits to only that file. Tagging worked well for me. Remember, taking small steps is the key. - Database migrations: Integrations with databases work nicely with v0 now. One edge case I noticed is that if you revert back to a version after which you had run some migrations, the migrations are not reverted. In some edge cases, the database might look different and cause errors in future updates. It isn’t a big issue if you are taking small steps because you can manually update the database, say, delete a table that v0 added but is no longer needed.
- Loading and error pages: The
loading.tsxanderror.tsxfiles are a feature of Next.js that improves the user experience. They work nicely on the deployed version, but sometimes lag or don’t work on the preview. You can always validate them on the deployed version because their logic is outside of the main page, so they don’t interfere with the app that much. - Page titles: Page titles and metadata may not work in the preview or new tab, but work fine on the deployed version of the app.
- Integrations in new tab: Integrations contain sensitive information, and because of the new tab context, you can’t view the preview version of your full stack application in a new tab. I use the deployed version to review full-screen changes.
I’ve passed on the feedback from this experience to our v0 team, and I’m sure we’ll see many improvements in the product.
Cost
I used my free v0 plan to do this. I think I was able to get to version 37 in a budget of $1.2. The main reason for this is that I used the small model for almost everything. I started with the medium model initially, but soon realized that I wanted to see the limits of the small model because I hadn’t used it intensively before.
Usage and billing screenshot
As you can see in the screenshot, I used the v0-1.5-md model only in the beginning and then to debug some issues in the middle.
Closing thoughts
I think v0 is impressive. It has quirks, but it’s a fabulous tool that is evolving faster than ever and maturing into a more stable product. I cribbed a lot about the things not working in the previous post, but I didn’t have that many complaints this time. If I can leave you with one thought, it is this:
Use v0 like you are working with an actual engineer by giving them small and descriptive tasks, letting them finish, reviewing the small update, and then moving on to the next one. Manage your expectations. v0 isn’t a magic alien technology from the movie Transformers , so you can’t expect it to take you all the way unless you work with it and support it—just like you would with yourself or your peers.
Show me the code
Here’s the final application: https://weekly-board.vercel.app, and the chat if you want to review.
Let me know in the replies what are some of your learnings from v0 and share your prompt hacks with everyone.