Vibe to Devhttps://www.vibetodev.com/ · free community resource
Launch checklist: 30 checks before you go live
A pre-launch checklist for websites and apps built by vibe coding with AI. Each item guards against a failure like these: a leaked API key, one user seeing another's data, a lost database, a surprise bill, a missing privacy policy. Tick what's done, and for anything you're not sure about, copy the prompt: your AI coding agent (Claude Code, Cursor, Copilot) checks it and shows you the evidence, and you decide whether it passed. Security is open to everyone; sign in free for the rest.
Security0/8
Leaked keys, missing permission checks and open databases. Most take a few minutes to check.
Secrets live in a secret store, never in code
Keep .env in .gitignore and give production its keys through your host's environment settings. Search the repo and the built JavaScript for sk_, key=, secret and the Supabase service_role key. Deleting the line does not help, because Git keeps every version: if a key was ever committed, rotate it.
Search this repo, its full git history and the production JavaScript bundle for API keys, tokens and passwords. List every hit with file and commit. Don't change anything; tell me which keys I must rotate at the provider.
Every permission is checked on the server
Hiding a button is not a permission. Sign in as user A, copy a URL or API call that belongs to user B, and try it. You should get a 403 or 404, never B's data.
List every API route and server action in this app. For each one, show the exact line that checks the signed-in user may access that record. Flag any route that trusts an id from the browser without checking ownership.
Database rules are on (Supabase RLS, Firebase rules)
If the browser talks to the database directly, the public key ships to everyone and the rules are the only lock. Every table needs row-level security with a policy per action.
List every database table, whether row-level security is enabled, and each policy in plain English. Then give me a test request I can run as a normal signed-in test user to verify it cannot read another user's rows.
HTTPS everywhere, one canonical address
Typing http:// or the address without www lands on the same https:// URL, with the padlock.
Check my live site: does http:// redirect to https://, do www and the bare domain end up at one address, and when does the TLS certificate expire? Show the real response headers as evidence.
Sign-up, login and contact forms are protected from bots
Rate limit per IP, add a CAPTCHA (Cloudflare Turnstile is free) on public forms, and verify emails before an account can do anything expensive.
Find every public form and every endpoint that sends an email, calls a paid API, or creates an account. For each, tell me what stops a script from calling it 10,000 times, and propose the smallest rate limit or CAPTCHA to add.
All user input is parameterized and validated
Forms, query strings, JSON bodies and file uploads. Queries are parameterized, output is escaped, uploads are limited by type and size. The browser's validation is a convenience, not a guard.
For every API route and server action, list the fields it reads from the request and show the line where each is validated on the server. Flag raw SQL built from strings, HTML rendered from user input, and any upload without a type and size check.
Dependency versions are current and audited, and the security headers are set
npm audit shows no critical issues and versions are pinned. The live site sends the security headers (Content-Security-Policy, X-Content-Type-Options, X-Frame-Options and HSTS): together they limit which scripts run, stop other sites framing yours and force HTTPS. CORS allows only your own domains, and production ships no source maps.
Run the dependency audit for this project and list critical and high findings with the fix. Then fetch my live homepage and report which security headers are missing, what CORS allows, and whether source maps are served in production.
Your own admin accounts have 2FA
GitHub, your host, your database, your domain registrar, your payment provider and your email. Whoever gets into one of these owns your app.
Give me a checklist of every account this app depends on (hosting, database, domain, DNS, payments, email, AI providers), with the settings page where I turn on two-factor login for each.
Data & Backups0/2
Code can be redeployed in a minute. Lost data can't.
- Backups exist, and you've restored one
- Never test against the production database
Monitoring0/4
The difference between a bad five minutes and a bad weekend.
- Errors reach you, grouped, with a stack trace
- Something outside checks the site every few minutes
- You know how to roll back, and you've tried it
- You can find the logs for a failed request
Billing & Renewals0/3
Problems that stay quiet for months, then arrive all at once.
- Every usage-billed service has a spending limit
- Payments use live keys, and the webhook is verified
- Domain auto-renew is on and the card on file is valid
Legal & Trust0/9
Cheap now, expensive after a complaint.
- A privacy policy that matches what the app really collects
- Forms ask only for what they need
- Cookies and trackers wait for consent
- A cookie policy that lists the real cookies
- Terms of use and real business details are published
- Consent is unticked, and marketing has its own checkbox
- If you sell: refund, returns and shipping policies
- No fake reviews, testimonials or numbers, and rights to every image
- Accessibility basics pass
Real-World Testing0/4
Not in your browser with your account. On a stranger's phone.
- It works on a real phone
- Emails arrive in the inbox, not spam
- A helpful 404 and error page
- The site has a title, description and link preview
🌙 Every item here is a lesson in the Production course, and the course keeps going after launch day.
- 64 topics, not 30 lines. Each one explained in plain words: what breaks, how to check it, and a worked example.
- 8 drills on your own app. Your AI adds error alerts, a robot that walks your main journey, a rehearsed rollback, a restored backup, database rules and spend caps, and shows you the evidence for each one.
- What to tell your AI at 3am. Every topic ends with the exact prompt for the moment it breaks. Here is one of them:
My last release broke something and it included a database change. Do not roll back yet and do not change the database. Tell me what the old code expects, what the database looks like now, and whether rollback, roll forward or a restore is the safest route.
Tickable version with copyable prompts: https://www.vibetodev.com/ai-vibe-coding-website-launch-checklist
Made by Vibe to Dev (https://www.vibetodev.com/), courses for people who build with AI:
- Behind the Prompt: How Your App Works: https://www.vibetodev.com/courses/advanced
- Ship & Sleep: Production for Vibe Coders: https://www.vibetodev.com/courses/prod