However you built it — Lovable, Bolt, v0, Replit Agent, Cursor, or a long ChatGPT session — you now have the same asset and the same problem: an MVP that demos perfectly, and no experienced dev team to tell you whether it survives contact with real users. Funded startups buy that judgment with headcount. This checklist is that judgment, in order, with the parts that automate automated.
The five defect classes that kill vibe-coded launches
- 1. Faked flows. The most common and the most dangerous: a payment, email or sync path that returns success without doing the work. The model mocks what it couldn't finish and reports done. Your demo can't tell; your first customer can.
- 2. Invented APIs. Plausible SDK calls that don't exist — verbatim from a real review: “stripe.Inventory is not a valid Stripe SDK resource.”
- 3. Demo-scale performance. “100 sequential HTTP roundtrips, ~10–20 seconds, blocking the event loop” — invisible with one user, fatal with a hundred.
- 4. No failure handling. Happy-path code: one API hiccup mid-flow leaves half-written data and no recovery. Demos never hit this; production hits it in week one.
- 5. Money math. Float dollars where the processor takes integer cents — rounding errors that surface as reconciliation mismatches you can't explain.
The checklist
Step 0 — get the code somewhere reviewable. Lovable and v0: sync/export to GitHub. Bolt and Replit: download or push the repo. Open it in Cursor, Claude Code, VS Code or Windsurf — you won't be reading it; your gate will.
Step 1 — install the reviewer (30 seconds). One click for Cursor, VS Code, LM Studio or Goose, or one line for Claude Code. 25 free validations per machine, no signup — enough to run this whole checklist.
Step 2 — gate the critical flows first. Ask your assistant to validate, one at a time: the payment path, the signup/auth path, anything that writes user data, anything that calls external APIs. “Validate the checkout flow with verificate” — fix what it rejects, re-validate until approved.
Step 3 — make the gate permanent. One standing rule turns launch review into continuous review:
Before presenting any substantive code change as complete:
1. Call validate_ai_output on the change.
2. If REJECTED: fix every finding and re-validate. Never skip silently.
3. Report what the gate caught - visibly, every time.Step 4 — the non-code launch basics. The gate reviews code; you still own: environment secrets out of the repo, a real database backup, error monitoring (Sentry-class), and a rollback path (your platform's deploy history usually is one). One afternoon, once.
What “reviewed” actually means here
Verificate runs 17 deterministic reality gates — mock/placeholder veto, invented-API checks, false-“done” detection — and any single gate can veto with no appeal. What survives is scored by a frontier-model review against the standards senior engineers use (ISO/IEC 25010: performance, reliability, scalability). Binary verdict, severity-ranked findings, production arithmetic included. Your assistant fixes and re-validates; you watch verdicts turn from REJECTED to APPROVED.
Start with your scariest flow: install the gate, validate the payment path, and let the first rejection show you what you were about to ship.