Vibe-Coded MVP Audit: 15 Red Flags Before You Scale

The audit

Run through these 15 categories. If you can't confidently answer yes to all of them, you have work to do before scaling. They are ordered by severity — fix the top half before you market.

1. Are your secrets in client code?

The single most common vibe-coded mistake. AI tools write code that imports API keys, database credentials, and admin tokens directly into client-side files. Anything in your Next.js client components or React Native bundle is public — your users can read it with the developer tools.

Look for: Any sensitive key in files outside .env and outside server-only code paths. In Next.js, anything not prefixed with NEXT_PUBLIC_ must stay server-side; anything that IS prefixed with that is public to the world. In Supabase apps, look for the service role key in client code — it gives admin database access if exposed.

2. Is row-level security configured correctly?

The most dangerous Supabase failure mode. Supabase apps use row-level security (RLS) to control who can read and write what. AI tools often either (a) disable RLS to make the app work, or (b) write policies so permissive they effectively allow anything. We have seen apps where any user could read every other user's data with one API call.

Look for: Tables with RLS disabled. Policies that only check true or that don't reference auth.uid(). Any table holding user data without explicit per-row policies. Test by logging in as user A and trying to read user B's rows.

3. Are you actually backing up production data?

Most vibe-coded apps have zero automated backups. The default Supabase free tier does not include point-in-time recovery. The default Firebase setup does not back up Firestore. SQLite apps running on a single server have nothing.

Look for: An automated backup that runs at least daily. Backups stored somewhere different from your primary data (cross-region, S3, or a separate account). A documented procedure to restore from a backup. The last successful restore test in the last 90 days.

If you cannot answer “yes” to all four, you do not have a backup strategy. You have a wish.

4. Does authentication actually authenticate?

AI tools sometimes wire up login flows that look right but skip the actual security checks. We have seen apps that issue session tokens before email verification, that don't check token expiry server-side, that store passwords with weak hashing, or that use client-side “is logged in” checks while leaving the API endpoints open.

Look for: Every API route validates the session on the server. Password reset flows require email verification. Rate limiting on login attempts. Tokens have an expiry and refresh strategy. MFA is at least possible.

5. Is user input validated server-side?

Client-side validation is for UX. Server-side validation is for security. AI tools often write only the first and trust the client to behave. They never do.

Look for: Every server endpoint validates types, lengths, and constraints before touching the database. SQL injection vectors closed (parameterized queries, not string concatenation). File uploads check size and content type server-side.

6. Are database migrations versioned?

AI tools often have you click around in the Supabase or Firebase UI to create tables. That means your schema lives only in production — no migration files, no version control, no way to reproduce the schema in a staging or local environment, no rollback if a change breaks.

Look for: Migration files in the repo. A way to spin up a fresh database from those migrations. A staging or local environment that mirrors production schema.

7. Does the app handle errors at all?

AI-generated code has a strong tendency to use try/catch blocks that silently swallow errors, or to skip error handling entirely and let exceptions crash the request. Either way you end up with mystery failures users can't recover from.

Look for: User-facing errors that are explained, not stack traces. Server errors that are logged with enough context to debug. Graceful fallback states when an API call fails. A way to retry transient failures.

8. Is anything observable?

Most vibe-coded apps have zero observability. No error tracking, no performance monitoring, no logs you can search. When something breaks in production, you find out from a user, you can't reproduce it, and you don't know how often it's happening.

Look for: Error tracking (Sentry, Rollbar, or similar). Server log aggregation. Basic uptime monitoring. Some kind of user analytics. At minimum: a way to find out about a 500 error without your customer telling you.

9. Is your dependency list secure?

AI tools install packages aggressively and rarely audit them. We often find vibe-coded apps using deprecated, unmaintained, or actively malicious npm packages. Some have hundreds of dependencies for what could be a 50-package app.

Look for: Run npm audit and check for high or critical CVEs. Look for packages with no updates in 2+ years. Look for any package you don't recognize doing more than the smallest possible thing.

10. Do you have separate environments?

Most vibe-coded apps have one environment: production. They test on prod, develop on prod, and deploy by pushing to main. There is no staging, no preview environment, no way to test a migration without affecting real users.

Look for: At least local + production. Ideally local + staging + production. CI that runs tests before deploys can hit production. A way to preview a change before it goes live.

11. Are payments handled correctly?

If you take money, payments are the highest-stakes part of your app. AI tools wire up Stripe integrations that work but have classic mistakes: not verifying webhooks, trusting the price the client sends, no idempotency keys, no reconciliation between Stripe and your database.

Look for: Webhook signatures verified server-side. Prices and amounts always calculated server-side, never trusted from the client. Idempotency keys on every charge. A way to detect and fix mismatches between Stripe and your DB.

12. Are file uploads safe?

AI tools often hand users a Supabase Storage or S3 client and let them upload directly. Common failures: no file size limit (someone uploads a 5GB file), no content type check (someone uploads an executable), no scanning for malicious content, no isolation between users' files.

Look for: Server-side checks of file size and type before upload completes. Filenames sanitized. Storage paths namespaced by user ID. Public buckets audited — if it's public, did you mean it to be?

13. Is there rate limiting anywhere?

Most vibe-coded apps have no rate limiting. Anyone can hit your signup endpoint a thousand times a second, brute-force login, scrape your data, or trigger expensive AI API calls until your OpenAI bill hits $50,000.

Look for: Rate limiting on login, signup, password reset, and any endpoint that hits a paid third-party API (LLMs, Twilio, sending email). A circuit breaker on AI API spend.

14. Is the deployment process actually a process?

“I push to main and Vercel deploys it” is fine for a prototype. For a product with real users, you need at least review and rollback. Most vibe-coded apps have neither.

Look for: Pull requests with at least one set of eyes before merging. CI that runs tests and a build. A documented way to roll back a deploy in under 5 minutes. Production deploys triggered from a protected branch.

15. Could you survive a full data loss event?

Imagine a worst case: your database is corrupted, your hosting account is locked, and you have to rebuild from scratch. How close to whole could you get? If the answer is “nowhere close”, you have a disaster recovery problem.

Look for: Backups you could restore from, in a separate account or provider. Source code in a git host you control. Infrastructure-as-code or at least a written runbook for rebuilding. Critical credentials stored somewhere other than the founder's laptop.

How bad is it, really?

Almost every vibe-coded MVP we audit fails at least 8 of these 15 checks. The most common pattern is failing 1-3 (secrets, RLS, backups), passing 4-7, and failing 8-15 (everything observability and infrastructure-related).

The good news: most of these are fixable in 2-6 weeks of focused engineering, not a rewrite. A vibe-coded app with a sensible data model is usually rescuable — the issues are in the production engineering layer, not the core architecture. See our post on Vibe Coding Rescue for what the rescue process actually looks like.

Priority order

If you can only do some of this work, do it in this order:

1. Stop exposed secrets — rotate any leaked keys today
2. Set up automated backups — daily, off-site, restore-tested
3. Fix RLS or equivalent — no cross-user data leaks
4. Lock down auth — server-side session checks, MFA option
5. Add server-side validation — every endpoint
6. Wire up error tracking — at least Sentry
7. Get migrations into version control
8. Add rate limiting on auth and paid APIs
9. Stand up a staging environment
10. Everything else

Frequently asked questions

What is the biggest problem with vibe-coded apps?

Security is the most common and most serious problem in vibe-coded apps. AI coding tools default to fast-shipping patterns that bypass real auth, expose secrets in client code, leave database access wide open via misconfigured row-level security, and skip input validation. The second-biggest problem is missing backups — most AI-built apps have no automated backup of production data, so a single bad migration or accidental delete can wipe out the business.

Are AI-built apps safe to use in production?

An AI-built MVP can be made production-safe, but it almost never is at launch. The default output of tools like Cursor, Lovable, Replit, and Bolt skips the production engineering work — backups, security hardening, error handling, observability, secrets management. You have to add that work explicitly.

How do I audit a vibe-coded app?

Check 15 categories: secrets exposure, authentication, row-level security, input validation, backup configuration, database migrations, error handling, observability, dependency security, environment separation, payment handling, file upload security, rate limiting, deployment process, and disaster recovery. Each one has specific failure modes in AI-generated code.

Can vibe-coded apps scale?

Yes, but rarely without intervention. Most vibe-coded apps can handle the first 50-200 users on their original stack. Beyond that, you typically hit issues with database schema decisions made early, missing indexes, no caching strategy, exposed Supabase or Firebase clients used as the API layer, and architectural choices that made sense for a prototype but not a product.