Is your AI-built app production-ready?
By Aakshar Garg, Founder, Scalable Systems · Last reviewed
the short answer
An AI-built app is production-ready when seven things hold: only the right people can reach your data, customers can't see each other's rows, no secrets ship in the browser, payments can't double-charge, traffic doesn't melt the database or the bill, you'd know it broke before a customer told you, and you could restore the data if it went wrong.
AI tools are genuinely good at building working software. What they don't do is the pass that happens after it works — the one where someone asks what a stranger could reach, what happens at a thousand users instead of ten, and what the recovery plan is. The failures below are what we find, over and over, in apps that were shipped straight from the builder.
What breaks first when real users arrive
Ordered roughly by how often we find it and how much it costs when it goes wrong. None of these are exotic — they're the standard consequences of skipping the review pass.
| What breaks | What you'd notice |
|---|---|
| No row-level access rules on the databasecritical | One customer opens their dashboard and sees another customer's orders. Usually discovered by the customer, in an email you don't want to receive. |
| No ownership check on an id in the URL (IDOR)critical | Changing /invoices/1042 to /invoices/1043 loads somebody else's invoice. The login worked; nothing checked whether that record was yours. |
| Keys shipped inside the browser bundlecritical | A key sitting in your JavaScript, readable in DevTools, that can run up charges on your account or read the whole database. |
| Payment writes that aren't idempotenthigh | A double-tap on Pay charges the card twice, or a retried webhook creates the same order twice. Refunds and apologies follow. |
| N+1 queries and missing indexeshigh | Instant with ten rows, unusable at ten thousand. A page that loaded in 200ms in testing takes eight seconds for your first real customer. |
| No rate limiting on auth or expensive routeshigh | Someone can hammer your login, spam signups, or run your most expensive query in a loop, and nothing stops them. |
| No error trackingmedium | The app has been failing for a segment of users for a week and there's no way to know until one of them writes in. |
| Backups nobody has restoredmedium | A bad migration or a bad delete, and no verified path back to yesterday's data. |
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.
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 breaks first when an AI-built app gets real users?
Almost always data separation, then money. Cross-tenant reads — one customer seeing another's data — are the most common critical finding, because getting them right requires database rules nobody thinks to ask for. Payment double-writes are second, 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, and under India's DPDP Act that obligation is real.
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. 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.
The seven-layer production check
Every audit we run walks the same seven layers, in this order. Each one is a question you can answer about your own app today — no tooling required.
- 1
AccessCan a stranger reach something they shouldn't?
authentication, session handling, ownership checks on every route
- 2
TenancyCan one customer see another customer's data?
row-level security, tenant scoping, IDOR on every id in a URL
- 3
SecretsWhat's shipped in the browser that shouldn't be?
keys in the client bundle, service-role credentials, token scope
- 4
Money pathsCan a customer be charged twice — or not at all?
idempotency, webhook retries, payment state reconciliation
- 5
Load and costWhat happens at a hundred times this traffic, and what's the bill?
N+1 queries, missing indexes, unbounded jobs, runaway spend
- 6
ObservabilityWould you know it broke before a customer told you?
error tracking, structured logs, alerting on the paths that matter
- 7
RecoveryIf the data went wrong today, could you get it back?
backups you've actually restored, reversible migrations, rollback
Sources
Every claim above about a third-party tool was checked against that tool's own documentation on July 26, 2026. These products change fast — if you spot something out of date, tell us.
Guides by tool
Want someone to actually check?
We audit AI-built apps against all seven layers and hand back a report in plain English — with the technical detail underneath for whoever fixes it. Startup-friendly pricing, scoped to your project.
Book an Audit