Probably not yet, and you don’t have to take that on faith. Of the 26 real AI-built apps AxonBuild has audited, zero came out green, 22 of 26 carried at least one confirmed critical finding, and scores ran 29 to 81 out of 100. Even the 81 wasn’t green. I ran those audits between June and July 2026, every finding verified against the code rather than pattern-matched, and the honest reading of the record is that “ready to launch” is a state almost no AI-built app starts in.
That verdict says nothing about whether your app is good. It works, the screens are real, the demo runs clean for strangers, and shipping all of that used to take a team a month. Launch readiness is a separate property. It lives in what happens outside the demo: the second account, the refund, the restore you never rehearsed. The useful move is to phrase it as a short list of claims you can check.
This post is the map of those claims. Seven questions decide most launches, each answerable in an afternoon, and each covered in depth by its own post if the short answer worries you. The audit data also answers a question most founders get wrong: which of those areas is probably your weakest.
”Production-ready” is a set of claims you can check
Strip the marketing off “production-ready” and a small, fixed set of claims remains: no keys reach the browser, one customer can’t read another’s data, the server confirms every payment before granting access, errors land somewhere a human will see them, and your data comes back after something deletes it. What makes code production ready in the fullest sense is a longer argument, but a launch decision doesn’t need it. Five or six claims carry most of the consequence.
Notice what kind of claims they are. Every one is checkable with the app you already have: two test accounts, a webhook log, a restore drill. None of them is answered by the demo going well, because from the outside, an app with those claims covered and an app without them look identical. Whether an AI-built app is production ready stops being a matter of opinion the moment you phrase it this way.
The seven questions a launch turns on
Here’s the same territory phrased the way I’d ask you directly. Read each as a question about your app, answered with evidence rather than memory, and follow the link when the honest answer is “I don’t know.”
Can a stranger pull your keys, or read another customer’s data?
AI tools optimize for making the demo run, and the version that ships a service_role key to the browser is indistinguishable in a demo from the one that doesn’t. Veracode’s 2025 GenAI Code Security Report found 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability, and 7 of the 21 third-party apps in the corpus let a logged-in user read or write another customer’s data. Why AI coding tools ship security holes by default explains the mechanism; what a vibe coding security audit actually finds is the field record.
If something deletes your data, can you get it back?
In July 2025, an AI coding agent deleted a company’s production database during a code freeze and then reported that rollback was impossible. Underneath the incident was one database with no isolation and no tested restore. A backup you have never restored from is a hope with a cron job attached, and the data-loss bugs hiding in your AI-built app covers the whole failure class.
When it fails, do you hear it from a dashboard or a customer?
17 of 21 third-party apps recorded errors nowhere. When a user hits a bug, nothing logs it, the bug just disappears, and the checkout that failed answers the same 200 OK as the one that worked. When your app fails silently and says 200 OK is the long version.
Can you ship a fix without editing your customers’ database by hand?
The default vibe-coded setup is one project that is the app: one database, no staging, and, in at least 17 of 21 audited apps, every push going straight to production with nothing checking it first. Rolling back the frontend does nothing, because the real deployment gap is the database.
Does it hold up when a hundred people arrive at once?
Your app is fast because you’re the only one using it. 13 of 21 audited apps had no rate limiting on their most expensive endpoint, so the first spike sets the bill along with the load. That cliff has a shape, and it arrives on your best traffic day.
Does the server confirm the money, or does the browser?
Two places can decide that a user paid: the browser, or your server after the payment provider tells it. 10 of 21 audited apps accepted whatever the browser asserted, prices included. The charge side is where a working checkout leaks money; the entitlement side, what your app grants after the charge, is how apps end up giving paid access away for free.
Can the next change be made without breaking the last one?
At least 23 of 26 audited apps had zero working automated tests, and the one that annoyed me most had a checkout “test suite” that never executed the checkout code: confidence purchased with nothing behind it. Without a tripwire, every new prompt is a regression risk, which is why your AI app gets harder to change every week.
What 26 real audits say your weakest area probably is
Ask a founder which of the seven they’d fail and most point at secrets: a key leaked to the browser, something scrapeable in the bundle. The data disagrees. Across the 21 third-party apps, secrets was the best pillar of the twelve, averaging 84.4 out of 100; most vibe-coded apps really do keep their keys in env vars. The worst pillar was reliability, at 31.4. The stereotype has the failure backwards.
| Rank | Pillar | Avg score (apps scored) | The plain reading |
|---|---|---|---|
| 1 (worst) | Reliability & correctness | 31.4 (21) | No working tests, errors recorded nowhere |
| 2 | Dependencies & supply chain | 34.5 (20) | Known-vulnerable versions ship and stay |
| 3 | Deployment & operations | 37.0 (21) | Push straight to production, no gate, no rollback |
| 4 | AI/LLM-native risk | 38.4 (14) | Strangers can burn the owner’s AI bill |
| 5 | Authorization | 42.1 (14) | “Logged in” is checked; “owns this row” is not |
| 6 | Revenue & billing | 42.7 (3) | Too few apps scored to trust the number |
| 7 | Data integrity & safety | 51.6 (20) | Backups unproven, destructive paths left live |
| 8 | Authentication | 52.8 (14) | Login works until an edge case arrives |
| 9 | Performance & scale | 53.3 (21) | Fine at one user, unmeasured at a hundred |
| 10 | Maintainability & evolvability | 61.1 (21) | God files and drift, but fixable |
| 11 | Input, injection & abuse | 61.9 (21) | The classic injections are mostly guarded |
| 12 (best) | Secrets & credentials | 84.4 (21) | Keys mostly stay in env vars; failures are rare but critical |
Averages come from the 21 third-party apps; pillars that didn’t apply to an app were excluded rather than zeroed, which is why the counts differ. Revenue and billing I can’t honestly rank for you: three scored apps is too few to call a trend, so the row carries a warning label instead of a conclusion.
I didn’t exempt myself from any of this. Before publishing the numbers, I ran my own five production apps through the same pipeline, and all five came back red, scoring 36 to 63. They failed where the table says they would: no working tests, every push landing on live users unchecked. I built them, I trusted them, and I still couldn’t see the gap from inside my own demos. That was the most useful thing the exercise taught me.
Vibe code keeps its keys and skips its tests: across the 21 third-party apps AxonBuild audited, the strongest pillar was secrets at 84 out of 100 and the weakest was reliability at 31.
The volume matters as much as the ranking. Those 21 apps produced 958 confirmed findings, roughly 46 per app, and only 58 were critical. Sorting the 6% that will hurt you from the 94% that can wait is most of the value of having someone look, and whether you need that at all is its own decision. When the answer is yes, the Beyond the Demo Audit answers the seven questions with evidence pinned to file and line, a different deliverable from a scanner’s severity list.
Why AI app launch readiness never shows up in a demo
A demo is one happy path, run by the person who knows exactly how the app is meant to work. Every one of the seven questions is about what happens outside that path: a second user, a malformed input, a cancelled charge, a deploy at the wrong minute, the hundredth visitor. A clean demo is evidence about the path it ran and silent about everything else.
Platform scans don’t close the gap either, because most of them are presence checks: they confirm a protection exists, and existence is a weaker claim than working. Lovable’s green check is the worked example of how far apart those two claims can sit on a real platform. Whether a vibe-coded app is ready for production is a question about wiring you can’t click on, and no amount of clicking answers it.
The AI-built app launch checklist, in order of consequence
The seven questions again, ordered by what the audit record says goes wrong first and costs the most when it does. Run them top to bottom, treat “I don’t know” as a no, and verify each one instead of recalling it. A list answered from memory is just the demo again.
- 01 Sign in as a second account and try to read the first account’s data; the attempt has to fail
- 02 Grant paid access only from the server, after the provider confirms the charge, and revoke it when money flows back
- 03 Restore from a backup once, on purpose, and time how long it takes
- 04 Route every error somewhere you will see it before a customer tells you
- 05 Put one gate between a push and production; a single test on signup and checkout is enough to start
- 06 Rate-limit your most expensive endpoint before the first traffic spike prices it for you
- 07 Keep the app changeable: one working test per critical path, so the next prompt can’t silently undo the last fix
If you’d rather have the ordering computed against your own answers, the scorecard walks the same twelve readiness areas in about two minutes, scores the nine it can measure from your answers, and names your weakest one.
Common questions before launch
Is my app ready to launch?
If real users, money, or data arrive at launch and you can’t yet answer the seven questions with evidence, then not yet, and the fastest honest path is to run the checklist above and count how many answers come back “I don’t know.” Zero of 26 audited apps started green, mine included. In every audit so far, readiness has been a state apps reach on purpose.
Is a weekend project ready to launch?
Usually not, and that’s fine. A weekend project is supposed to prove the idea works, which is a different job from surviving strangers and their credit cards. The honest move is to run the seven questions once, write down which ones you skipped, and make each skip a decision instead of an omission.
How long does hardening take?
Most of the highest-leverage fixes are an afternoon each rather than a rebuild: an isolation test with two accounts, the payment grant moved behind a verified webhook, error tracking turned on, one test each on signup and checkout, a restore drill run once. Taken in order of consequence, a week of afternoons covers most of the list. It’s a hygiene pass rather than a do-over.
Do I need this if my platform already scanned my code?
A platform scanner confirms a protection exists in the code. Whether it works is a separate claim, and one the scanner can’t test: catching a logged-in customer reading another customer’s invoices takes two real accounts and a request the scanner never makes. A policy that reads using (true) passes “row-level security is enabled” and leaks every row. The only proof is behavioral: run the flow the way a real user, or a curious one, actually would.
What’s the actual difference between “it works” and “production-ready”?
“It works” is a claim about the happy path you demoed. “Production-ready” is a claim about everything else: the second user, the failed charge, the traffic spike, the bad deploy, the accidental delete. Across 26 audited apps, the distance between the two claims was wide enough to measure, with a mean score of 52 out of 100 and a green bar none of them reached.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
