Vibe Coding to Production: A Founder's Readiness Guide

Moving from vibe coding to production is a change of job, not a change of tool. In a prototype, the goal is to see something work. In production, the goal is that it keeps working when real people use it badly, when a third-party service goes down at midnight, and when you need to change something without breaking everything else. An AI tool can get you to the first goal quickly. It will not get you to the second unless you ask for it, and you need to know what to ask.

This guide is for founders who built a first version with AI coding tools and now want to put paying users on it. It uses primary sources: Andrej Karpathy's original post that named vibe coding, the 2025 DORA report, Google's Site Reliability Engineering book, the Twelve-Factor App methodology and Veracode's 2025 GenAI Code Security Report. We have not taken any specific app to production for this article. The checklist at the end is our own synthesis of those sources, and we label it that way.

What vibe coding was meant to be

Karpathy described vibe coding in February 2025 as a new kind of coding where you fully give in to the vibes and forget that the code even exists. He said he always clicks "Accept All," no longer reads the diffs, and pastes error messages back in with no comment. When the model cannot fix a bug, he works around it or asks for random changes until it goes away. Source

Read the end of that post closely. He called it "not too bad for throwaway weekend projects." Andrej Karpathy on X That is the honest scope of the original idea. Nothing in the post says that code nobody has read is ready for customers. The distance between a weekend project and a service people pay for is where the rest of this article lives.

AI makes you faster, and that is the risk

The 2025 DORA report, based on survey responses from nearly 5,000 technology professionals plus more than 100 hours of qualitative data, found that about 90% of respondents use AI at work and more than 80% believe it has raised their productivity. About 30% report little or no trust in the code AI generates. Source

The more useful finding is about stability. Unlike the year before, DORA observed a positive relationship between AI adoption and both delivery throughput and product performance. But AI adoption continued to have a negative relationship with software delivery stability. The authors' reading is that AI accelerates development, and that acceleration can expose weaknesses downstream. Source

They name what helps: strong automated testing, mature version control practices and fast feedback loops. Without those control systems, an increase in change volume leads to instability. Their headline is that AI amplifies what is already there, so strong teams get better and struggling teams find their problems intensified. Source

For a founder, the translation is direct. If you can generate ten changes a day, you need a way to know whether change number seven broke the signup flow. A prototype has no such net. A production app needs one before it needs more features.

What code from a model actually looks like on security

Veracode tested more than 100 large language models on coding tasks in four languages. In 45% of samples, the generated code failed security tests and introduced a vulnerability from the OWASP Top 10. Newer and larger models were no better at security than older ones, even as they improved at producing code that works. Source

This is why "it works" is not a launch criterion. If you want the specific database and access control checks, we cover them in our post on how to audit vibe-coded apps before launch. The short version is: test your app as a stranger, not as yourself.

What Google asks before launching a service

Google's SRE book includes a launch coordination checklist, described as the original checklist from around 2005, slightly abridged. You do not need Google's scale to borrow its categories, because each one names a way launches fail. Source

The headings are: architecture, machines and datacenters, volume estimates and performance, system reliability and failover, monitoring and server management, security, automation and manual tasks, growth issues, external dependencies, and schedule and rollout planning. Source

Under reliability, it asks what happens when a machine dies or a network fails, how to detect when a backend dies, how to restart without affecting users, how rate limiting, timeouts, retries and error handling behave, and how data is backed up and restored. Source

Under external dependencies, it asks about third-party systems, graceful degradation, and how to avoid overrunning third-party services. Under automation, it lists a release process, repeatable builds, canaries under live traffic and staged rollouts. Under schedule, it even says to think about launching on Mondays or Fridays. Source

A founder app does not need N+2 datacenter redundancy. It does need an answer to "what happens when the payment provider or the AI API is down?" and "can I restore last night's database?" If the honest answer to either is "I don't know," you have found work to do before launch.

Config and logs: two cheap habits from Twelve-Factor

The Twelve-Factor App methodology has two rules that vibe-coded projects often break. The first is to keep configuration out of the code. It defines config as everything likely to vary between deploys, including database handles, credentials for external services and per-deploy values such as the hostname. Storing these as constants in the code violates the method, which asks for a strict separation of config from code. Source

It offers a litmus test: could the codebase be made open source at any moment without exposing any credentials? The Twelve-Factor App If an AI tool pasted an API key into a source file for convenience, the answer is no, and that key should be rotated and moved to environment variables.

The second rule is to treat logs as event streams. Logs give visibility into how a running app behaves, and the method says each process should write its events to standard output, leaving routing and storage to the execution environment. In staging and production, that environment captures the streams and sends them to wherever you view and archive them. Source

The practical point for a small team is that you need to be able to see errors from real users after launch. If your app only logs to the browser console, you will find out about failures from angry emails.

A gap that the sources do not fill

None of these documents tells you which tool or host to pick, how much traffic you will get, or whether your idea is good. DORA's findings are survey-based and describe organizations, not a two-person startup. The SRE checklist is from a very large company. Veracode tested code samples, not shipped products. We use them because they are primary and because each one points to a failure that vibe-coded apps are prone to, but you should judge which parts fit your situation. That judgment is ours.

A founder's readiness checklist

This checklist is our synthesis of the sources above. The ordering and wording are ours.

1. Someone has read the code that touches money, logins and personal data. Karpathy's workflow, where diffs are not read, is fine for a throwaway. For anything people trust you with, a human should read these parts. Source

2. You have an automated test for your main paths. Sign up, log in, pay, and the one thing your product does. DORA ties stability to automated testing and fast feedback. Source

3. Your code is in version control, with changes you can undo. DORA names mature version control practices as part of the safety net. Source

4. You have tested the app as an outsider for access control holes. This is the main security result to act on. Source

5. No secrets live in the code. Pass the open-source litmus test from Twelve-Factor. Source

6. You can see errors and key events in production. Logs go somewhere you will actually look. Source

7. You know what breaks when a dependency fails. Payment, email, AI API, database. Decide what the user sees. Source

8. You have restored a backup at least once. A backup you have never restored is a hope. This wording is ours; the SRE list names backup and restore as a launch item. Source

9. You can release in small steps and roll back. The SRE list mentions repeatable builds and staged rollouts. Source

10. You picked a launch day with someone available to fix problems. The SRE list's note about Mondays and Fridays makes the same point. Source

Where we can help

If you have a prototype and want to take it to a version you can put real users on, our vibe coding for founders service is built for that step. If your product includes AI agents, our AgentOps services page covers tool access, permissions and monitoring.