Abhi Vaidyanatha

10 hours ago

6 Steps Before Taking your Vibe-coded App to Production

Current AI code generation workflows allow you to go from idea to POC in record time. Then, they fall apart as you try to move to production without the experience of deploying production-grade applications. Below, I will show you how to overcome this barrier with some product management principles.

First, I will go over some basic concepts that will help you iterate on your product and make your code more maintanable. Then, I’ll suggest some milestones to hit before moving your application to production. Lastly, I'll provide the questions you need to ask yourself as you evaluate the move to prod. I believe that Convex provides the easiest transition to production, as state management problems (caching, database optimization, scheduling) silently plague early app ideas, which Convex completely handles for you. This article might feel like overkill, but if you’re really serious about an idea, this will save some future headaches when your code needs to be managed by humans or AI in the future.

1. Share it with friends

Let’s start with a fun one. When developing, it’s wild how many blind spots I backed myself into while building solo. I totally missed product pitfalls that were obvious to external people, who prevented me from launching with glaring design mistakes. AI agents are not humans and will often create product mistakes without understanding the consequences.

For example, by default, Chef automatically configures auth and creates a login screen for you that allows users to sign up or login anonymously. Normally, this is awesome and takes care of a big challenge in traditional app development. However, one of the most common complaints I got was that users didn’t want to click “Login Anonymously” to try out the app. When I ended up removing anonymous login altogether in production, it was a way bigger refactor than it should have been, because agents had coded my app to expect certain elements to be persisted server-side with the anonymous user. Since anonymous users weren’t tracked anymore, I had to bake in client-side (not stored by the database) logic that I could have designed at a way earlier stage.

The takeaway here is to share your product early, where architectural changes and iterations can happen a lot faster and with less consequences. Convex allows you to share your dev deployment link and directly push to it, which makes sharing your early POC straightforward.

2. Understand your critical path

Odds are, there are a few functions in your app that get called more than others, as they represent the core functionality and identity of your app. AI tools make it incredibly easy to instrument complex patterns and then let you blissfully make life or death decisions for your app without warning you. As a vibe-coder, understanding the “critical path” that your app executes most often is more important than understanding the other 95% of your codebase.

To implement this in practice, after doing some demo runs of your app, I would recommend going to your function logs and looking through which ones are being invoked most often and which ones take longer than 400 ms (read more about the Doherty threshold). Go find those functions in the code and skim the code. It’s okay if you don’t understand everything, the most important thing is that you’ve been there. Now every time your agent tries to make a change to one of these critical functions, you can recognize that it has a chance of being a big change.

For example, I asked an agent to implement an achievement system in my game and it started to place achievement logic directly in the game path, making the code that governed the main function that was being called over and over again over twice as long. Because code review is difficult in most vibe coding tools, you might completely ignore this and move on, accepting that it technically works.

However, I questioned the decision, and actually looked up what game designers usually do for achievements. What I actually wanted was an event system that would prevent having to manage sprawling if statements in my critical function and more complex achievement criteria. All I did afterward was ask the AI to question the decision, consider the event / observer pattern, and I specifically told it:

“Please please please do not agree with me for the sake of agreeing with me. Actually evaluate what would be the best pattern for this codebase in the short, medium, and long term.”

I don’t know if this attempt at getting it to be impartial worked, but it was emotionally important for my sanity, as I needed an unbiased answer to a critical technological fork in the road.

Ultimately, Claude evaluated that the event system I suggested was better for the medium term. The biggest takeaway: AI coding tools will agree with you, even if you’re not qualified to make these technical decisions. Question everything.

3. Optimize your critical path

Now that you know what your most important functions are, you can work toward making sure that they are algorithmically efficient, optimally interacting with external APIs, and following good database hygiene. Thankfully, you can just ask your agent to introspect all your code for you, but don’t immediately trust it. If able, you should ask the same optimization questions to many different models in your vibe coding tool, as some are better at evaluating general concepts like optimization and others are best at simple tasks.

Remember, specific prompts are better! Now that you know your critical function names, you can ask questions like, “On line 78 in example.ts, we define the brewSoup function. Evaluate all algorithmic inefficiencies in this implementation and make sure that it’s not doing more reads from the database than necessary. Use the schema in schema.ts to leverage indices where relevant.” Doesn’t that sound a lot better than “Make my app faster?” If you keep asking generic questions, the agents will understandably not have a lot to go off of here and will start applying random changes to your app. You are working with a model that has been trained on human code and software engineering principles, so it should be interfaced with as such.

I’m a little biased here, but using Convex as my backend means that my database reads are already cached, I can’t write functions that scan too many documents, and I have a beautiful primitive called Actions to interact with external APIs optimally. This automatically solves a lot of the optimization questions for me. If you’re not using Convex, you’ll need to trust the AI to implement your own cache, SQL database, and have some logical code split between the backend and frontend.

4. Evaluating full-stack readiness for prod

You want to use the pre-prod phase to cover as much ground as possible before introducing code review and CI barriers. These barriers, while really important for production code, will reduce the speed at which you add features to your application; make sure that all of your main functionality is complete. Consider the following questions to ask yourself:

Is my database schema still changing often?

If you’re still changing your database schema and object structures, you would probably be significantly slowed down by moving to prod. These changes are a lot more difficult to manage when your production data is sacred and can’t be nuked at will. Coding agents can help you write migrations once you get to production, but won’t evaluate the mental stress that comes with actually running them.

Do I have any destructive workflows?

Sometimes in the development process you get used to annihilating the data in your tables, creating a workflow that requires fully destroying all of your data every time you make a change. This is unfeasible for production, as you want to treat data as sacred once you’re there. This is a good sign that you are not ready to move to prod. Evaluate these workflows and get a few non-destructive changes under your belt first.

Is my application UX ideal?

Applications become slower over time as libraries and extensions cause bloat in your code, so you want to launch with an app that feels snappy out of the gate. If you have dependent external API calls that add significant latency to certain functionalities, add an Action Cache or ask your agent to optimize the external calls. Apply the Doherty threshold to every part of your app by keeping all visual feedback under 400 ms, as users will absolutely notice if it is violated. Make sure to test latency on your dev deployment, not just your local one, as that will show you the true latency of your functions.

Is my UI reasonable?

Default UIs are often not ready to be shared with the public and lack polish. Get feedback from friends about your UI and ask Chef or your AI coding tool of choice to focus on individual small changes to your UI. General prompts such as “make this look prettier” will put you in a state of constant churn whereas specific prompts such as “apply a solid drop shadow to my button elements” will give you a fairly deterministic outcome. This is where understanding design language and applying many small edits will give you a leg up.

5. Do a cleaning pass

Finally, once you’ve finished the feature set and UI, you want to make sure that your code is readable. It may be tempting to skip over this, but you have a great once-in-a-lifetime opportunity to use your vibe-coding tool to do a bunch of chores for you. You may ask:

Why is readable code important if it’s only AI programming tools interfacing with it?

This is because AI tools are almost entirely dependent on context. They either pull from a stored context that you’ve generated in recent conversation, a squashed context created over time from a lot of chat logs, or they have to start fresh by evaluating what’s in front of them. Because of this, having clean code that makes sense out of the gate, accurate comments, and minimal code errors is pretty ideal for AI, not just humans.

Also, there were multiple instances that I asked a human to review my changes and having the code naturally be clean made it less embarrassing.

If you haven’t already, have your AI coding tool do the following:

• Install ESLint and fix all linter errors
• Install Prettier and apply some standard code formatting
• Ask your AI coding tool to read all the comments it wrote and delete everything that is obvious or outdated. Agents fail to clean up old comments quite often and your code becomes impossible to understand with incorrect text everywhere.

Here’s one massive final pro-tip for improving your code.

If your AI coding tool supports it, provide it blogs and docs as context and ask the agent to look over your code and adopt the standards that the docs and blogs suggest. For example, TypeScript and Convex are powerful because you get to enforce strong types, but you may not have a good idea of how to take advantage of this. All I did was refer my AI agent to this blog post and it automatically refactored my schema to generate validators and types. Providing the right context goes a long way to making sure your foundational code is strong in the long run.

6. Evaluating the move

The main reason to move into production is to set up your app on your own domain, hosting service, and add continuous integration. If you’re developing on Chef, here is a guide that goes over the basics of moving to production. I would ask the following questions before moving:

How will I write code on my own?

You want to find an AI app building tool that works locally. My favorite tool is Claude Code because I prefer the command-line experience, but if you’re less used to that, Cursor is the more general option for a full code editor. Most people don’t suddenly start coding everything themselves, make sure that you are set up to function outside of the vibe coding tool.

How will I set up GitHub?

1. Follow the steps here first to set up your code locally.
2. Make an account on GitHub.
3. Set up an SSH key to remotely transfer and retrieve your code to the GitHub servers.

If you haven’t worked with Git before, here is an actually simple guide to use to understand what’s going on. Additionally, if you truly don’t want to understand version control, you can ask your agent to write Git commands for you, but I’d recommend at least figuring out what’s going on.

If you’re not ready to use GitHub yet, I would recommend not moving to production. You’ll notice I didn’t cover other methods of version control, which you don’t really need to concern yourself with if you’re just trying to get up and running.

Where will I host my website?

Vercel and Netlify are your best bets. We have hosting guides for them here. The hosting platforms will have easy guides to set up your own domain name once you’re live.

A reasonable conclusion

While it’s easy for me to make a lot of recommendations, I have to be self-aware enough to understand that I didn’t learn a lot of these lessons until I actually went to production. The most important thing is a working product that people actually want to use, so if you take some shortcuts to get there, I don’t blame you. However, there is a large difference between intentionally taking a shortcut versus letting your model make it for you. If you’re going to At the very least, evaluate which best practices you will follow and which ones you will eventually adopt in the future.