Hi fellow community members, I had been dabbling with v0 for a while now. Inspired by what you all had been building using v0, I also tried my hands at building a Personal Workout Tracker application. This seems like a fairly easy job with v0, but there’s a twist: I used v0 to build out the full stack application end-to-end. In this post, I’ll take you through my learnings and take aways from this experience.
Getting started
To get started, I laid down the most basic requirements I could come up for my application. I was impressed to see that v0 took this single message and created a full plan to implement the application. What stood out to me was that its plan included the part about “persisting data” and the related backend API.
This is what I got as the version 1 of my application, pretty impressive huh!
The UI structure is great. It’s nice that v0 came up with mock data to fill the UI with. Although, the UI isn’t what I was expecting it to be. But, after re-reading my prompt, I realized I could have done a better job. I specified “When I log, I see the list of exercises I’m supposed to do today”, whereas what I actually meant was “Show me a dropdown of the exercises I’m supposed to do today in the log workout form”. As expected, giving a better prompt got me the results I wanted.
Developing the application
I was off to a good start. I kept iterating over the design and functionality of the workout logger. By the 11th iteration, I got the application working as expected but using the mock data and inputs that v0 had set up for me. We had the form to select an exercise from the list of exercises available for that day, add weights and reps for each set.
Setting up the backend
Now that the frontend part was done, it was the time to move off to the backend integration with Neon. I gave v0 a very basic prompt:
Let's add the persistence part. How about we use neon db to store the list of exercises for the week, the log workout.
Based on this prompt, it went on to suggest the whole process for setting up a database using Neon, setting up the environment variables, and the necessary dependencies. The UI didn’t change much but the number of files increased in my project.
As you can see in the image, v0 added a SQL schema, database utility functions, and the API routes to perform the actions required for my application. It then prompted me to add the environment variable for my Neon database. But, my application wasn’t working now: the exercise dropdown was empty and there were two errors popping up in the preview tab.
In the chat window, I noticed that after adding the environment variable, v0 created a script to setup the database and also shared the instructions to run it locally.
When I prompted v0 to run the script, it again shared the steps to run the project locally. After cloning the project locally, I ran the script and it worked fine for me. I checked the database and the data was present there. It was an “Aha!” moment for me. I’m impressed by how v0 guided me throughout the process, even for the steps I had to perform locally.
However, being a heavy Drizzle ORM user, I couldn’t overlook the fact that v0 didn’t use an ORM and neither did it use SQL migrations to set up the database, which in my opinion would be the way to go for any project bigger than a demo application.
Deploying the application
After the database integration, I added some loading states and fixed some frontend issues. Now, the minimal viable version of my application was ready now. I was also able to deploy the application to Vercel just by clicking Deploy and I was able to test the live version right away.
It worked like a charm for me. But, just in case it doesn’t work for you, I recommend reading this community post with troubleshooting guides and tips that may come handy.
You can try the live version of the app using this link.
Learnings and recommendations
- Know what you want to build. A list of feature set and requirements will help give you the clarity to write better prompts. This should ideally include what the finished project will look like and how it’ll interact with the users.
- Keep your prompts as clear and descriptive as possible. Enforce your requirements wherever it seems required. For example, when making a form input, the requirements can help v0 handle validation and set error messages.
- The v0 version history is great to compare different versions of the application. For example, I remember when I updating the form logic at one point the form got updated in terms of design as well. So, I used the version history to view the last version where I liked the form layout and restored the UI.
- When working with backend, double check if the logic isn’t leaking any sensitive information. Explicitly ask for a server action or an API route based on your use case. For example, for frontend components, Server Actions are preferred. However, if you are building a webhook or API endpoint then API routes are the way to go.
- Creating a database using v0 isn’t bad if you know what you’re doing. Patiently follow through the instructions and cross question v0 about why is it suggesting
- When working with databases, carefully notice the schema design v0 is suggesting, the scripts to populate the database, and the backend logic it creates. v0 might not use the best practices or the project structure you might be used. So, you can always prompt v0 to follow a certain style guide or make those changes locally yourself.
Conclusion
I was able to get my personal workout tracker app out in a few hours and that is just mind blowing! The credit also goes to Vercel and Neon for the ease of setting up projects and databases but v0 did a lot of the heavy lifting for me.
v0 is amazing for frontend development, it understands your design language, follows good frontend coding practices, it is fast to iterate over your ideas, and quickly takes you from idea to a product. However, v0 isn’t there yet on the backend side of things. It can suggest solutions and iterate quickly on the backend as well. But, due to the severity and importance of backend logic, you should still rely on developer experience to get the database and backend logic checked.
So, will I use v0 to build a full stack app again? Yes. Will I review and update the backend for best practices and safety? Yes.