Is your AI-built app production-ready?

What is a vibecoded app?

A vibecoded app is one built mostly by describing what you want to an AI tool — Bolt, Lovable, v0, Cursor, Replit, Claude Code — instead of writing the code line by line. The code is real, and often good. What's usually missing is the review pass that catches the problems which only appear once strangers are using it.

The distinction that matters isn't AI versus human. It's built versus reviewed. An AI tool optimises for the thing you asked for working, and it will happily give you a working app whose database is readable by anyone who signs up. Nobody asked it not to.

Is my MVP ready for real users?

Usually not yet — and that isn't a criticism of the build. An MVP is optimised to prove someone wants the thing; real users test what happens when a stranger is holding it. The gap is nearly always the same three: whether customers can reach each other's data, whether anything with real privileges sits in the browser, and whether a payment can be taken twice.

The reframe that helps: an MVP answers does anyone want this? Production answers what happens when someone careless, unlucky or hostile uses it? Nothing about answering the first question forces you to answer the second, which is why apps sail through launch week and fall over in week three — the failures need real traffic, real concurrency and real strangers to show up at all.

How do I know if my app is production-ready?

Walk the seven layers below and answer each question about your own app. If you can't answer one confidently — especially tenancy, secrets, or money paths — that's the gap, and those three are the ones that cost real money when they fail.

You can do a surprising amount of this yourself in an afternoon. Open your app in two browsers signed in as two different accounts and try to reach the first account's data from the second. Open DevTools, look at the Network and Sources tabs, and search your own JavaScript for anything resembling a key. Neither takes any tooling, and both find real problems.

What is my vibecoded app missing?

Almost always the negative requirements — the rules about what must not happen. You asked for features and got them; nobody asks for "and make sure user A can't read user B's invoices", "and don't let this payment run twice", "and tell me when it breaks". What's missing is rarely a feature. It's the constraints around the features you already have.

The recurring absences, in the order they cost you money: access rules on the database, an ownership check on every id in a URL, rate limits on login and anything expensive, idempotency on money paths, error tracking, and a backup someone has actually restored. Every one of them is invisible while the app works — which is the whole problem, because the app does work.

What breaks first when an AI-built app gets real users?

Usually data separation, then money. Cross-tenant reads — one customer seeing another's data — are broken access control, which OWASP ranks as the number one web application security risk, and they are easy to ship because getting them right requires database rules nobody thinks to ask for. Payment double-writes come next, because retries only show up under real traffic.

Performance failures feel more dramatic but are usually cheaper. A slow page annoys people; a leaked customer list is a breach you may be legally obliged to disclose — under GDPR within 72 hours of becoming aware, and under India's DPDP Act to both the Data Protection Board and every affected person.

If that is happening to you right now, start here: why one user can see another user's data — the six causes, the test for each, and what to do in the first hour.

Can I fix these myself?

Several of them, yes. Rate limiting, error tracking, and moving a key out of the front end are well-documented jobs with clear finish lines. The two worth getting help with are database access rules and payment paths, because both fail silently — the app keeps working while being wrong.

That's the honest split. If you read this page, fix three things, and never talk to us, the page did its job. The seven-layer production check gives you the test and the fix for each layer; our guides for Lovable, Bolt.new and v0 go tool-by-tool, and the Supabase RLS checklist covers the single highest-risk layer in detail.

What does an audit include that a code review doesn't?

A code review asks whether the code is good. An audit asks what a stranger can do with it, what it costs at scale, and what happens when a dependency fails. It's adversarial rather than stylistic — we try to reach data we shouldn't, submit things your forms don't allow, and replay requests to see what happens twice.

Concretely: automated scans plus a human reading the paths tools can't judge, every finding ranked by severity and effort, and a report written in plain English up top with the technical detail underneath for whoever does the fixing. The process is three steps, starting with a call.

Do I have to hand over my code?

No. A repository is the fastest route, but a live URL works, and if you're in stealth a description of the stack is enough to scope the work. We'll sign an NDA before you send anything — just ask.

How long does an audit take?

Days, not weeks, for most apps. The exact scope comes out of a 30-minute call where we look at what you've built; small apps are quick and a large multi-tenant system with payments takes longer.