Your Vibe-Coded App Passed the Demo.
Will It Pass an Audit?

AI coding tools have made it trivial to get from idea to working demo. They have not made it trivial to get from demo to production. Those are different problems, and the industry is currently pretending they're the same one.

A demo needs to work once, in front of a friendly audience, on a good day. Production needs to work every day, under load, for strangers, while holding real data it's legally responsible for. Nothing about a fast demo tells you whether the app can do the second thing — and increasingly, founders are finding out the gap exists only after they've onboarded real users onto something that was never built to hold them.

Why do vibe-coded apps fail in production?

This isn't hypothetical. One of our own engagements is a direct example: a UK dental practice built a vibe-coded practice management SaaS, got it to 5–10 live users, and then hit a wall. Not a feature wall — a foundations wall. No CI/CD. No compliance layer. No path from "this works on my machine" to "this can legally hold patient data." The founder didn't need more features. They needed someone to make the thing they'd already built safe to keep running.

That's an audit problem, not a rebuild problem — and that distinction matters, because most agencies will quote you a rewrite when a stabilisation is what you actually need. A rewrite resets your product to zero and bills you for the privilege. A stabilisation keeps what works and fixes what doesn't. Any agency that jumps to "rewrite" before mapping your system is telling you what's easiest for them, not what's right for you.

What does a production readiness audit actually check?

These are the four areas where vibe-coded applications most often fail — and the four questions any serious audit has to answer.

• Structural stability. Are there undocumented interdependencies that break when touched? Vibe-coded systems are frequently held together by implicit assumptions no one wrote down, because no one had to — the AI that generated the code doesn't leave a design doc.
• CI/CD and deployment safety. Is there a repeatable, tested path to production, or is shipping a manual, held-breath process that depends on one person remembering the steps?
• Compliance and data handling. For anything touching personal, financial, or health data: access controls, audit trails, encryption, and the specific regulatory regime your sector answers to — GDPR, HIPAA, PCI DSS, or whichever framework applies. AI tools generate code that runs; they do not generate code that complies.
• Dependency and build hygiene. Outdated or unpinned dependencies, unresolved build errors, and the general drift that accumulates when code is generated faster than it's reviewed.

Can the gaps be fixed without taking the product offline?

Yes. The hard part isn't identifying the gaps — it's closing them while the product stays up, because by the time a founder asks for this audit, real users are usually already on the platform. In the dental practice case, active practices were using the system throughout the entire stabilisation.

That constraint dictates the method. Map the system fully before touching anything. Prioritise structural stability over speed. Make every change in an order that keeps the live product running. This is also where a lot of well-meaning developers get it wrong — the enthusiasm to "just rewrite it properly" is exactly the instinct to resist first. Enthusiasm doesn't keep a live system up. Sequencing does.

What the outcome looks like when it's done right

The dental practice platform went from 5–10 early users to 15 onboarded practices by the end of the initial engagement — commercially ready, compliant, stable. It has since grown to 500+ UK dentists on the platform with a 4.9-star rating, on a GDPR and HIPAA compliance footing that would have been unreachable on the original codebase. The full story is in the Dentistry Dashboard case study.

None of that required a rewrite. It required someone to treat "AI got us to a demo" and "we're production-ready" as the two separate questions they actually are.

Frequently asked questions

What is a production readiness audit?

A structured review of an existing codebase against the four areas above — structural stability, deployment safety, compliance and data handling, and dependency hygiene — producing findings you can act on with any team. It answers one question: what stands between this app and production, and in what order should it be fixed?

Do I need a rewrite or an audit?

If your app already has real users and mostly works, start with the audit. Most agencies default to quoting a rewrite because it's simpler for them to price — an audit tells you whether one is actually necessary. In the dental practice case above, it wasn't.

Can a vibe-coded app become GDPR or HIPAA compliant?

Yes. Compliance is a property of the whole system — access controls, audit trails, encryption, data handling — not of who or what wrote the first draft of the code. The dental platform above reached GDPR and HIPAA compliance on its original codebase, without a rewrite.