Production readiness for vibe coded apps

Bob Starr built a website called Boomberg to track US tax money flowing to tech companies. He shipped it the day he finished vibe coding it. Months later, he learned his site had a problem severe enough to make The Verge write about it.

That story is not an outlier. It is the default outcome when vibe coding meets the public internet without an engineering layer between them. The tools are extraordinary at producing something that runs. They are indifferent to whether it should.

Why vibe coding breaks in production

Vibe coding optimises for the demo. You describe what you want, the model writes plausible code, and the preview loads. The loop is intoxicating because the feedback is visual and immediate. What you do not see is everything the model assumed: that your API keys belong in the client bundle, that authentication is somebody else's job, that the database is open to the world because that made the prototype work.

Research from Georgetown's CSET found that AI generated code contains exploitable vulnerabilities in roughly 30 to 50 percent of cases depending on the language and task. Stanford researchers have repeatedly shown that developers using AI assistants write less secure code while feeling more confident about it. The vibes are, by design, misleading.

This matters because vibe coded apps are no longer toys. Founders are shipping them to paying customers. Internal teams are deploying them to handle real data. The gap between prototype velocity and production rigor is now a business risk, not a craft preference.

What "production ready" actually means

Before we get to the framework, a definition. Production ready does not mean perfect. It means a system fails in known ways, recovers in expected timeframes, and does not leak data or money when it does fail. Three properties sit underneath that: the system has boundaries, the system has visibility, and the system has a kill switch.

Most vibe coded apps have none of these. They have features.

A production readiness framework for AI generated code

Use this as a gate before any AI generated codebase touches a real user or real data. It is deliberately short. Long checklists get skipped.

1. Secrets and surface

• No credentials in client code, repo history, or environment files committed anywhere.
• Every external API call goes through a server you control, not directly from the browser.
• Database access requires authentication, and the default rule is deny.
• Cross origin policies are explicit, not whatever the framework defaulted to.

If you cannot answer these in under five minutes, you have not shipped a product. You have shipped a liability.

2. Identity and authorisation

• Authentication uses a known provider, not hand rolled token logic the model invented.
• Authorisation is enforced server side on every endpoint, not hidden behind a UI route guard.
• Admin paths require a second factor and are not discoverable from the public site.

The most common vibe coding failure is an endpoint that trusts the request because the UI would never call it that way. Attackers do not use the UI.

3. Data handling

• Personally identifiable information is classified before storage, not after a breach.
• Backups exist and have been restored at least once in a drill.
• Deletion actually deletes, including from logs, analytics, and AI training pipelines you forgot you enabled.

4. Observability and limits

• Errors are logged somewhere a human will see them within 24 hours.
• Rate limits exist on anything that costs money per call, including LLM endpoints.
• A spending cap on cloud and model providers is set below the number that would end the company.

The AI coding tools that wrote your app will happily wire up a model endpoint that costs ten dollars per request and call it on every page load. Cost is a security property now.

5. Change control

• Production deploys go through a pipeline, not a chat window.
• Someone other than the original builder has reviewed the code that handles auth, payments, or data.
• There is a documented rollback procedure that takes minutes, not hours.

Where this fits in the build process

The framework is not anti vibe coding. Speed of prototyping is a real advantage and pretending otherwise is romantic nonsense. The point is to be explicit about which phase you are in.

In the exploration phase, vibe code freely. Ship to yourself, ship to a handful of friendly users behind a login, learn what the product wants to be. In the commitment phase, when real users or real money show up, the production readiness layer becomes non negotiable. That transition is where most teams stumble because the original builder is rarely the right person to harden the system. They are emotionally and cognitively attached to the working demo.

This is the moment where a Fractional CTO earns their fee. Not by rewriting the app, but by drawing the line between prototype and product and enforcing the gate. For investors evaluating a company built on AI generated code, the same framework doubles as a Technical Due Diligence checklist. If the target cannot answer the five sections above, the post deal engineering work is larger than the deck suggests.

What we see in client work

At Devspace we are increasingly called in after the vibe coding phase, when a founder or an internal team has shipped something that works and now needs to survive contact with auditors, enterprise customers, or growth. The pattern is consistent. The product logic is usually fine. The infrastructure underneath it is a minefield of default permissions, embedded secrets, and silent failure modes.

The takeaway

Vibe coding is not the problem. Treating vibe coded output as finished software is the problem. Build fast, then run the five section gate before anything real touches it. If you cannot pass the gate, you have a prototype, not a product, and that is a useful thing to know before your users find out for you.