Is Your Vibe-Coded App Production-Ready? A Checklist

AI coding tools are very good at one thing: making the app work in the demo. That's exactly what you asked for, so that's what you got.

Production is a different standard. It means the app keeps working when real users do things you didn't expect, when someone actively tries to break it, and when money and personal data are involved. AI tools routinely leave out the parts of software that only matter under those conditions: access control, secrets handling, input validation, backups. Not because they can't write them, but because the demo works without them.

I'm a technical PM and an ex-engineer. This is the checklist I run before a vibe-coded app gets real users. It isn't a substitute for a professional security review once you handle payments or sensitive data, but it catches the holes that show up most often.

Security

Keep secrets out of the browser

Anything in your frontend code is public. Anyone can open the browser's developer tools and read it.

• No secret API keys (payment, email, AI provider, admin database keys) in client-side code. Only keys designed to be public belong there.
• Secrets live in environment variables on the server, never in the repository.
• Search your built JavaScript and your git history for keys. If one ever leaked, rotate it. Deleting the line doesn't un-leak it.

Lock down database access

This is the most common serious hole in vibe-coded apps. If your app talks to the database directly from the browser (common with Supabase and Firebase), the database rules are your only security.

• Row-level security, or the equivalent rules, is enabled on every table that holds user data.
• Test it as an attacker would: log in as user A and request user B's records by changing an ID in the request. If you get the data, so can anyone.
• Admin-only actions are enforced on the server, not just hidden in the interface.

Check authorization on every request

Hiding a button isn't access control. Every endpoint that reads or changes data should check who's asking and whether they're allowed, on the server.

Validate input and rate-limit public endpoints

• Validate and length-limit every input on the server, even if the form already checks it in the browser.
• Rate-limit login, signup, password reset and any endpoint that sends email or costs you money (AI calls especially).
• Add basic spam protection to public forms. On my own site, the contact form validates everything server-side and uses a hidden honeypot field that bots fill in and humans never see.

Handle payments safely

• Prices and amounts are set on the server. Never trust a price sent from the browser.
• Verify the signature on every payment webhook before acting on it.
• Grant access based on the payment provider's confirmation, not on the user landing on a "success" page.

Keep dependencies honest

• Dependencies are up to date and audited. AI tools sometimes suggest outdated or even nonexistent packages, so check that every package is real and maintained.
• Skim the OWASP Top 10. Most issues in AI-generated code map to it.

Reliability

• Backups run automatically, and you have tested restoring one. A backup you've never restored is a hope, not a backup.
• Error monitoring tells you when users hit errors, before they tell you (or don't, and leave).
• Uptime monitoring alerts you if the site goes down.
• A staging environment or preview deployments, so changes are tested before they reach users.
• You can roll back a bad deploy in minutes.

Email that actually arrives

If your app sends sign-in links, receipts or notifications, deliverability is part of production.

• Send from your own domain, with SPF and DKIM records verified. I set this up for productwithandrew.com with Resend, and it's a few DNS records that decide whether your emails land in the inbox or in spam.
• Test every transactional email on Gmail and Outlook before launch.

Findability: can search engines see your app?

Vibe-coded marketing sites often look perfect in the browser and nearly empty to search engines and AI crawlers. I found two of these issues on my own site:

• Content shouldn't depend on JavaScript to become visible. My entrance animations started every section at zero opacity and faded them in with JavaScript. Without JavaScript, the page was blank. Make sure your content is in the HTML the server sends.
• Structured data must be in the initial HTML. Mine was injected after the page loaded, so crawlers that don't run JavaScript never saw it.
• Every page has a unique title, meta description and canonical URL, and your sitemap lists the pages you want indexed.

Test this yourself: view the page source (not the inspector) and check that your main content is there.

Legal and trust basics

• Privacy policy that matches what you actually collect, including analytics.
• Terms of service, and a refund policy if you sell anything.
• A real way to contact you.
• If you have users in the EU, consent handling for non-essential cookies.

Measurement

• Analytics on the one action that means a user got value, not just page views. Without it you can't tell whether a change helped. (More on this in why your app isn't making money.)

When to bring in a professional

Get an experienced engineer to review the code, or a security tester to try to break it, when any of these become true:

• You take payments directly or store payment-related data.
• You store sensitive personal data: health, financial, identity documents, private messages.
• You have enough users that a breach would make news in your niche.
• A business customer asks for a security questionnaire.

A review at that point costs a fraction of what a breach does.

The point isn't perfection

You don't need all of this to show a prototype to ten people. You need all of it before you ask strangers for their data or their money. Ship fast to validate the idea, then make it solid before you push for growth.