Launch Gate — Security & Production-Readiness Audit

The problem

You built it with Lovable, Bolt, v0, Cursor or Claude Code. It works. You're about to put it in front of paying users — and you have a feeling: is the service_role key in the bundle? Did the agent ever write an RLS policy? Can someone POST a fake checkout.session.completed? What happens when a bot hits /api/chat 10,000 times tonight?

Independent scans in 2026 found that more than 9 in 10 AI-generated apps shipped with at least one critical vulnerability, and that around 1 in 10 indie launches exposed Supabase credentials in the frontend. Free security prompts tell your agent to "look for issues". They don't give you a verdict, and they don't tell you what to fix first.

What it does

Launch Gate turns your coding agent into the last reviewer before go-live. It detects your stack, runs an offline pre-scan (Python stdlib, no network, no env access), then reads the code module by module and returns:

• A 0–100 score and a binding verdict — SHIP / FIX FIRST / HOLD — computed by fixed rules, not vibes.
• Findings per file with severity, why it matters, the patched code, how to verify, and effort.
• "Do these three first" — the highest-impact fixes with time estimates.
• What passed — the controls that are fine, so you (or your client) can see the full picture.
• 12-point production-readiness checklist — monitoring, logging, backups, env separation, headers, dependencies, DB rails, cost controls, legal pages, AI disclosure.
• Dashboard checks it can't see from the repo, with exact click paths (Supabase backups/auth settings, Stripe webhook mode, provider spend caps).
• Optional client-facing report for freelancers and agencies (--client-report).

Six modules, loaded only when they match your stack:

1. Secrets & env — keys in source/bundles/git, NEXT_PUBLIC_/VITE_ secrets, service_role on the client, secrets in logs and error responses, rotation checklist.
2. Database access — Supabase RLS (tables, policies, storage, views, RPC, realtime) with read-only SQL you can paste; Firebase Rules; Convex; Prisma/Drizzle IDOR and mass assignment; Mongo operator injection.
3. Auth & sessions — server-side user resolution, scoped queries, Server Actions, middleware-only auth and CVE-2025-29927, cron/internal routes, cookies; Supabase Auth / Clerk / Auth.js specifics.
4. Payments & webhooks — Stripe signature on raw body, idempotency, entitlements from events not success pages, server-owned prices, subscription lifecycle; Lemon Squeezy, Paddle, Polar, Svix.
5. API & AI abuse — unauthenticated or unlimited AI routes ("cost bombs"), per-user quotas, rate limits, max_tokens, model allow-lists, tool-scoped agents, prompt-injection paths, SSRF, uploads, XSS, CORS.
6. Production readiness — the 12-point checklist with copy-paste snippets (security headers, fail-fast env schema, health endpoint, AI disclosure copy).

Stacks covered: Next.js (App/Pages), Remix, Nuxt, SvelteKit, Vite SPAs, Express/Fastify/Hono, FastAPI/Django · Supabase, Firebase, Convex, Prisma, Drizzle, Mongo · Supabase Auth, Clerk, Auth.js, Firebase Auth · Stripe, Lemon Squeezy, Paddle, Polar · OpenAI, Anthropic, Gemini, Vercel AI SDK and more · Vercel, Netlify, Cloudflare, Fly, Railway, Docker.

Why this beats prompting it yourself

• Deterministic verdict. Severity definitions and the score formula are written down; two runs on the same code give the same answer. A prompt gives you a different essay every time.
• It knows the 2026 failure modes. Stripe webhooks parsed with req.json(), success pages that upgrade accounts, dangerouslyAllowBrowser: true, RLS using (true), the Next.js middleware bypass, AI routes with no quota — each has a check, a severity and a fix template.
• Offline pre-scan that respects secrets. Decodes Supabase JWTs to tell anon from service_role without ever printing the key; masks everything after 6 characters.
• Read-only by design. Nothing is changed unless you say "apply the fixes", one diff at a time.
• Client mode. Agencies get an executive summary with risk → impact → remedy → effort, and a technical appendix.

Use cases

• Solo founder launching a Lovable/Bolt/v0 SaaS this week.
• Freelancer asked to "just check" a client's vibe-coded app before it goes live — bill the report.
• Agency adding a security gate to every delivery.
• Team migrating a prototype to production: run it in CI-like fashion before each release.
• Anyone who just added payments or an AI feature to an existing app.

Known limitations

• Static review of the repository; dashboard settings and live infrastructure are reported as VERIFY items with click paths.
• Tables created in a BaaS dashboard rather than in migrations are invisible to the scanner — the skill hands you SQL to check them.
• Not a penetration test of a live URL; not a substitute for one if you process regulated data.
• Severity rules are strict on purpose: HOLD means "fix before launch", not "bad code".