Before real users touch your vibe-coded app, check data access, secrets and backups first

Today in AI (2026-10-15)

xAI launches Grok Voice 3.0, a fast talking AI built for customer support: AI that can hold a natural phone or voice conversation in under a second makes voice support and voice features realistic for small startups without a call center.
Google's Deep Review checks complex documents for errors and weak claims: Founders could soon get rigorous, expert-style feedback on technical specs, proposals and research documents without hiring a specialist reviewer.
Anthropic adds tracking tools to see what Claude agents are doing: Teams building on Claude can now see step by step what their AI features did and where they failed, which makes them easier to debug and trust in production.

A prototype built with an AI tool can look finished and still not be safe to hand to real users. It demos well because the demo is the one path someone tested. Real users take every other path.

The short answer: before launch, your app needs ten things. Real accounts and permissions, secrets kept out of the code, a real database with backups, real integrations, error handling, monitoring, a way to deploy and roll back, tested payments and emails, a privacy basics pass, and a load and abuse check. The list is below, with what a good answer looks like for each.

I build MVPs with AI coding agents (Claude Code) on Cloudflare daily, so I'm not against AI-built software. I'm against shipping it unchecked.

Why a working demo proves so little

"Vibe-coded" means you described what you wanted and an AI tool wrote the code while you steered by feel, without reading it closely. That is a fine way to get a prototype. The risk is that nobody has verified what happens off the happy path.

A demo shows one user, clean data, a good connection, and no one trying to break anything. Production is the opposite. Many of the shortcuts the tool took to make the demo work (sample data, shared logins, keys pasted into files) become problems the moment strangers arrive.

I've reviewed agency-built and contractor-built codebases as an interim or fractional CTO. I expect AI-built ones to fail in the same places, so the checklist below is where I would look first.

The production-readiness checklist

Ask your builder (or the AI tool itself) each question. You want a specific answer you can verify, not "yes, it's handled."

Accounts and permissions. Can user A see user B's data? Try it: create two accounts and attempt to open the other's records by changing the address in the browser. Good answer: every request checks who is asking, on the server, not just in the screen.
Secrets out of the code. Passwords, API keys (the private codes that let your app use other services), and database credentials should live in a settings vault, not in the files. Search the code for them. If any were ever committed (saved into the code history, where they stay even after you delete them from the file), replace them, because they are already exposed.
A real database with backups. Many prototypes store data in a temporary place that resets or disappears. Ask where the data lives, who can access it, and when it was last restored from a backup. A backup you have never restored is a hope, not a backup.
No fake data and no fake integrations. AI tools often hardcode sample results (write fixed fake results directly into the app) or simulate a connection to a payment or email service so the demo looks complete. I covered how to catch this in the four-point review of AI-written code. Run every integration once with real credentials in a test mode.
Error handling. What does the user see when something fails? A blank screen or a raw error message is a support ticket and a trust problem. Good answer: a clear message, and the failure recorded somewhere you can read.
Monitoring. You need to know the app is broken before a customer tells you. At minimum: an alert when the site is down, and a log of errors. Tooling here is getting better. Anthropic just added a standard way to record each step its AI agents take, so if your product uses AI agents, you can now see what they are doing rather than guess.
Deploy and rollback. Can you push a fix safely, and undo it in minutes if it breaks things? Good answer: a separate test copy of the app (a staging environment) where changes are tried first, and a one-step way back.
Payments, emails, and messages. Test the full loop: sign up, receive the confirmation email, pay, get a receipt, cancel, get refunded. Check that emails do not land in spam and that a failed payment does not leave a user half-subscribed.
Privacy basics. Know what personal data you collect, where it is stored, and how a user deletes their account. Have a privacy policy that matches what the app actually does.
Load and abuse. What happens with 100 people at once, or one person hitting the signup button 1,000 times? You do not need massive scale. You need to know the app slows down gracefully and does not run up a surprise bill with your AI provider.

Common mistakes

Asking the AI "is this production ready?" It will say yes. Ask for specific evidence instead: show me the test, show me where the key is stored.
Trusting a green checkmark. AI-written tests sometimes test nothing. A test that cannot fail is not a test.
Launching to everyone at once. Start with 5-10 friendly users. Real behavior finds problems no checklist does.
Skipping the spec. If the app's rules were never written down, nobody can verify them. A one-page spec fixes that for both people and agents.
Having no owner. Someone must be responsible for fixing things at 11pm. If that is nobody, you are not ready.

What has changed recently

Producing code is now cheap. One recent essay on AI and software delivery argues that this moves the bottleneck to deciding, verifying, and coordinating, and that adding more agents does not fix weak coordination. For you, that means the hard part of your launch is no longer writing the app. It is checking it. This checklist is that checking.

Review tools are improving too. Google's Deep Review is built to check complex documents for errors and weak claims, starting with PDFs and plain text. It is not a code auditor, but it shows where things are heading: AI that reviews, not just AI that produces. Use it on your spec and policies, and keep a human accountable for the code.

If you are still choosing tools, pick one per job, including one for review.

What to do this week

Copy the ten points into a document and mark each one pass, fail, or unknown.
Treat every "unknown" as a fail. Ask your builder for evidence on each.
Fix points 1, 2, and 3 first. Data leaks, exposed secrets, and lost data are the failures you cannot undo.
Run the two-account test from point 1 yourself. It takes ten minutes and needs no technical skill.
Launch to a handful of users, not everyone, and watch the error log daily.

If most of your list is "unknown", that is normal for a prototype. The point is to find out before your users do.