Is your vibe-coded prototype safe for production?

Usually not yet. And that is not a failure. A prototype’s job was to prove the idea, and a vibe-coded one did that fast. Production is a different job. The same code now has to hold up with real users and real data. Whether yours is ready comes down to a handful of specific things. Most of them are fixable, and you can check them yourself.

What does “production-ready” actually mean?

Production-ready is not the same as working. A demo works. Production-ready means the software behaves once the conditions get hard.

It handles input you did not plan for. It keeps data correct when many people use it at once. It fails safely and tells you when it does. It protects the data it holds. And someone on your side can change it later without fear.

A prototype clears almost none of those by design. That is the right call while you are still proving the idea. It becomes the problem the day you ship.

Why does code that works in a demo break in production?

The honest reason is in how the code got written. An AI agent builds what you described, and you described the thing working. So it nails the success path and leaves the rest thin.

A demo has one user, clean input, and a friendly audience. Production has none of that. The prototype did not get worse. The conditions got harder.

Where do vibe-coded prototypes actually break?

The gaps cluster in six places. None of them mean the prototype was bad. They mean it was built for a demo.

• Security fundamentals. Secrets and API keys sit in the source, or get shipped to the browser. Sign-in is bolted on late, or missing. Often there is no check that one user cannot reach another user’s data. Input is trusted without being validated, and that is how leaks start.
• Happy-path code. The success case works. The empty state, the timeout, the half-finished payment, the double-click do not. Each one is a support ticket or a broken record waiting to happen.
• The data layer under load. SQLite or an unindexed table is fine for one person clicking through a demo. It will not survive fifty people writing at once. And with no migrations, every change to the database risks the data already in it.
• No tests. Nothing catches the next change that quietly breaks the last feature. This matters more with vibe-coded code, not less, because no person held the whole design in their head.
• No way to see failures. When something breaks at 2am, there are no logs and no alerts. You hear about it from a customer, not from your own tools.
• Infrastructure. Backups, a deploy you can roll back, secrets kept properly, somewhere to run that is not a laptop. Prototypes usually have none of this.

How can you tell if yours is ready?

Run through this quick check. Answer no to any of them, and that is where the work is.

• Are your secrets and API keys held on the server, out of the source code and the browser?
• Can one user be stopped from reaching another user’s data?
• Is every input from outside checked before you trust it?
• When something it depends on goes down, does the app fail with a clear message?
• Will the database cope with a hundred people using it at once?
• Can you change the database without putting existing data at risk?
• If a feature broke today, would a test catch it before a customer did?
• When something fails in production, do you find out from your tools or from your users?

Eight no’s is a rebuild. One or two is an afternoon. Most prototypes land somewhere in between.

What does it take to make one safe?

Start with an audit, not a rebuild. Most vibe-coded prototypes are worth keeping. The product decisions inside them are often right, and that is the expensive part to get correct. The code is the cheaper part to make safe.

So the order is simple. Read the prototype. List the gaps by severity, with the effort to close each one. Keep what works. Rebuild only what cannot survive production. Scrapping a prototype that found real signal is usually the wrong call, and an expensive one.

When should you bring someone in?

If the prototype is heading for paying customers or anyone’s sensitive data, get an honest read before you scale it, not after the first incident.

That is how we start every hardening job. A fixed-price audit, with a written list of what survives to production and what does not, across security, data, tests, observability, and infrastructure. You get the gaps and the cost to close each one, in plain terms. If you go ahead with the work, the audit fee comes off the price.

The first conversation is free and takes under an hour. If your prototype is closer to ready than you feared, we will tell you that too.

If that sounds useful, start a conversation →.