The Vibe-Coded App Safety Checklist

You built something with AI. Before you put it in front of real users, run this.

A working app is not the same as a safe app. The most common problems with AI-built apps aren't in the code — they're in the configuration the builder didn't set up for you: who can see the app, where the secrets live, whether the database enforces its own rules, and whether a user can quietly change their own permissions. This checklist walks you through each one in plain English. No code required. If anything here is unclear or comes back red, that's the moment to get a second set of eyes — not a reason to panic.

Score yourself as you go: Green = verified safe. Yellow = unsure / needs a look. Red = confirmed problem. Any Red, or more than a couple of Yellows, means do not invite real users yet.

1. Visibility — is your app actually private when you think it is?

• I know whether my app is public or private, and it matches what I intend.
• The project/source (not just the running app) is not publicly viewable.
• Anyone with the link cannot see data that should require a login.
• I've opened the app in a private/incognito window (logged out) and confirmed I can't reach anything sensitive.

2. Secrets — are your keys where they belong?

• My API keys (OpenAI, Stripe, database, email/SMS) are stored as server-side secrets / environment variables, not pasted into the app's frontend.
• I've confirmed no secret key appears when I "view source" or open the browser dev tools network tab.
• My service-role / admin database key is never used in the browser — only the limited public key is.
• If I ever pasted a key into a chat, screenshot, or public repo, I've rotated it.

3. Authentication and isolation — can users only see their own data?

• The app has real login/authentication (not just a hidden URL).
• One logged-in user cannot see or edit another user's records by changing an ID in the URL.
• Admin / premium / paid status is enforced on the server — a user can't flip it in the browser to upgrade themselves.
• Sensitive actions (delete, export, pay, change role) check who's asking on the server every time.

4. Database rules — is your data enforcing its own access?

• If I use Supabase/Postgres, Row Level Security (RLS) is enabled on every table with real data.
• I've tested that a normal user cannot read or write rows that aren't theirs.
• No table that holds personal or business data is readable by "anyone with the public key."

5. Limits — can someone run up your bill or break the app?

• There are rate limits on the actions that cost money (AI calls, email/SMS, file processing, payments).
• There's a spend cap / alert on my AI, payment, and hosting accounts.
• File uploads (if any) are size-limited and type-checked.

6. The basics that make it real (production, not demo)

• Data is backed up, and I know how to restore it.
• I can roll back a bad change.
• I get an alert if the app goes down or errors spike.
• Someone owns this app's maintenance (it's not "set and forget").

Per-tool quick notes

• Lovable / Bolt / v0 — strong for fast UI; double-check project visibility, that secrets are server-side, and that any backend/database has auth + RLS, not just a pretty frontend.
• Replit — use Secrets for keys (never hardcode); confirm your deployment isn't exposing a dev endpoint publicly.
• Base44 — review app access settings, roles, and data permissions explicitly; confirm SSO/access controls behave as you expect.
• Cursor / Claude Code — more power, more responsibility: you own the repo, so you also own secrets handling, auth, tests, and review.

What an expert checks that a builder won't

If you'd rather have someone confirm it for you, this is the exact scope a security-minded developer reviews: secret placement and rotation, authentication and per-user data isolation, database access rules (RLS), admin/role enforcement, payment handling, rate/spend limits, input validation, and a sane backup/rollback/ownership plan.

That's what AgentC does — and we'd rather show you than tell you. Describe your idea or your existing app and we'll build you a working, safe version of what you're picturing, free, so you can see the difference instead of taking our word for it.

More than vibes: requirements, review, security, tests, and a launch path. You're not wrong to be excited. You're also not wrong to want a second set of eyes.

Related reading

• Is your AI-built app safe to put in front of customers? (the full guide)
• The pre-launch security checklist for Lovable, Replit, Bolt, and Base44
• What should you ask an expert to audit in your AI-built app?

Written by Seth Tucker, AgentC Consulting. Background securing U.S. election infrastructure and SOC 2 / ISO 27001 environments. Last updated 2026-06-13.