From Vibe-Coded Prototype to Production: The 12-Point Audit
The prototype works. You built it yourself in a fortnight, mostly by describing what you wanted and accepting what came back, and it does the thing. Now someone wants to pay for it — and the question you cannot answer is whether it is safe to let them.
This is now one of the most common conversations we have. Vibe coding won the adoption argument: JetBrains’ January 2026 pulse survey puts 90% of developers using at least one AI tool at work. The unresolved question is what happens between a working prototype and a product with real users, real money and real liability attached.
Here is the audit we run. Twelve checks, roughly in the order we run them, with the honest verdict at the end about what usually needs rewriting and what usually does not.
1. The Security Six
Always first, because these are the findings that turn a soft launch into an incident. Every one of them is something we have found in a real prototype.
.env files, hardcoded database URLs, a service key that reached the client bundle. Scan the full git history, not just the current tree — rotation is the only fix once it is pushed.Log in as User A, capture a request, replay it with User B’s identifier. If you get A’s data back, stop the launch. This one test finds more real vulnerabilities in AI-assisted prototypes than any scanner we run.
2. The Correctness Three
3. The Operability Three
4. So Does It Need a Rewrite?
Usually not. This is the part most people expect us to get wrong in the other direction, so let us be specific.
The business logic in a vibe-coded prototype is typically fine, because it encodes something you understood well and described clearly. What is missing is the surrounding layer — the authorisation checks, the validation, the tests, the error handling, the operability. That layer is additive. It bolts on.
What genuinely forces a rewrite is a data model that cannot express what the product now needs to do. If entities are wrong at the schema level, everything above them is built on sand, and patching gets more expensive than restarting. That is the one check worth doing before any of the twelve above: can this schema represent the next six months of the roadmap? If yes, harden it. If no, redesign the model and reuse the logic.
Either way, the prototype was not wasted. It is the most precise specification of your product that has ever existed — every screen, every rule, every decision, made concrete. That is worth considerably more than the document you would otherwise have written.
If you are in the hardening case, the MVP gap describes exactly that last mile. If you are commissioning someone to do it, how to brief an app development agency covers what to send them — and yes, “here is a working prototype” is a genuinely excellent brief.
Point us at the repo.
We run this twelve-point audit as a fixed-scope engagement and come back with a prioritised findings list, a harden-or-rebuild verdict, and an honest estimate for each path.