Resource

The AI app launch checklist.

50 items across 6 categories. 12 are non-negotiable. Run through it before you ship — or ask us to.

By Hyder ShahFounder · Afterbuild LabsLast updated 2026-04-15

Direct answer

AI builders ship the happy path and hide the unhappy paths. This 50-item list is the pre-launch audit we run on every Lovable, Bolt, v0, and Replit app before real users arrive. Twelve items are non-negotiable. Skip the rest at your own risk — every one of them maps to a failure we've seen in the rescue queue.

Why every AI-built app needs this

Vibe-coded apps pass the demo bar easily. A Lovable prompt gets you a working sign-up flow in an afternoon; a Bolt chat gets you a working Stripe flow the same day. What neither of them does is the post-demo hardening — idempotency, RLS, email DNS, env var discipline, rollback plans. Industry benchmarks put AI-code vulnerability rates close to half — see our 2026 vibe-coding research. The widely-reported Lovable/Supabase RLS disclosure described exactly the gap this checklist is designed to close.

The list below is ordered by damage-on-launch, not alphabetically. The first twelve items are the ones that cause a five-figure or six-figure incident when they're missing. The remaining thirty-eight are the ones that cause stalled launches, support queues, and bad investor conversations.

Pre-launch product

☐Pricing page exists and works
☐Onboarding flow tested by someone non-technical
☐Empty states are designed (no blank screens)
☐Error states are designed (no raw stack traces)
☐Email notifications send and look right
☐Mobile experience tested on real devices
☐Core flows have a happy-path Loom recorded
☐Support email/contact path is wired up
☐Privacy policy + terms published
☐Cookie banner (if applicable) doesn't block content

Code & QA

☐TypeScript strict mode enabled (or equivalent)
☐Lint and format passing on main
☐Critical paths covered by tests (auth, payments, data writes)
☐No `console.log` in production code
☐No hardcoded secrets or API keys
☐Error tracking (Sentry) wired up
☐PII fields identified and audited
☐Rate limiting on public endpoints
☐Input validation on every form/API
☐Manual QA on the 5 most-used flows

Auth, DB & payments

☐Row-level security verified for every table
☐Password reset works end-to-end
☐Email verification works end-to-end
☐OAuth providers tested
☐Session expiry/refresh tested
☐Stripe webhooks verified with stripe CLI
☐Failed payment + retry path tested
☐Subscription state syncs with DB
☐Database backups configured + tested
☐Migration history checked into repo

Deployment

☐Production env vars set (and not in repo)
☐Custom domain + SSL working
☐Email DNS records configured (SPF, DKIM, DMARC)
☐Staging environment matches production
☐CI/CD pipeline running tests on PR
☐Preview deployments work for branches
☐Rollback procedure documented and tested
☐Robots.txt + sitemap.xml deployed

Monitoring & backup

☐Uptime monitor pointed at production
☐Error tracking alerts wired to Slack/email
☐DB backup verified by restoring to staging
☐Log retention configured
☐On-call rotation defined (even if it's just you)
☐Dashboard for key metrics (signups, payments)

Post-launch first week

☐Submit sitemap to Google Search Console + Bing
☐Verify analytics is recording events
☐Watch error rate hourly for 48h
☐Reply to first 10 user emails personally
☐Document any production issues in a runbook
☐Schedule the first follow-up audit (30 days out)

The 12 non-negotiables, expanded

Skip any of these and the odds of a public incident inside 90 days go up sharply. Every one of them ties to a pattern we've fixed for a paying customer.

RLS on every Supabase table. Default is off for new tables in some scaffolds; one missing policy equals “the anon key returned everyone's rows.”This is the dominant Lovable incident pattern — write policies per role, then hit each endpoint with a second user's token to confirm.
Secrets out of the repo. Grep for every API key name across history, not just the current tip. If a secret was ever committed, rotate it before launch.
Error tracking live. Sentry, PostHog, or equivalent. You need a stack trace when the first user emails you; do not rely on users to narrate the bug.
DB backups verified by restore.“Backups are running” and “backups restore” are different claims. Restore to staging, diff the counts, and write the runbook.
Stripe webhook verification and idempotency. Verify the signature, insert event.id into a unique-indexed events table first, return 200 on duplicates, return 5xx on genuine failure so Stripe retries. Skip this and double-charges are a question of when, not if.
Env vars in a manager. Vercel, Doppler, 1Password — anything but the repo or a shared doc. Test-mode vs live-mode keys must be separate env vars, never swapped with a feature flag.
SSL live on the custom domain. Not the preview URL. Not with a wildcard redirect loop. HTTP to HTTPS with HSTS and a clean Lighthouse security score.
Sitemap submitted. Google Search Console and Bing Webmaster, with canonical URLs matching the sitemap. Get the index pass started before launch day; indexation lag is the silent SEO tax.
Error-rate watch for 48 hours post-launch. Hourly, by a human, with a phone on. This is the window where the worst regressions surface.
PII audited. List every field that qualifies as PII under GDPR/CCPA, document retention, and confirm deletion paths actually cascade.
PII access control. Per-role access policies enforced in the database, not at the application layer. Anything else is one bug away from disclosure.
PII deletion path. A user-facing delete button that actually removes data, not a soft-delete flag. GDPR Article 17 is not optional.

Per-tool notes

The same checklist applies, but the common failure points shift by tool.

Lovable. RLS, deploy env vars, and Stripe webhook idempotency. The RLS audit is the single most important item; see our Supabase RLS guide.
Bolt.new.Preview vs production env drift. The WebContainer injects variables the real host doesn't. Expect to re-wire every integration after export.
v0. No backend by default, so the backend items land on whatever you wire up. Most common gap is server-action auth around database writes.
Replit Agent. Cold-start latency and deploy sizing. Reserved VM is usually worth the premium for a launch-stage app.
Cursor / Claude Code.The code is yours; the checklist is your team's job. The failure mode is skipping the audit because "a human wrote it" — the industry AI-vulnerability benchmark applies to AI-assisted code too.

When to run this

Run it once three days before launch, then once on launch day, then once seven days after. The three-day pre-launch pass catches the work; the launch-day pass catches the regressions you introduced while fixing; the seven-day pass catches the scale bugs the first 100 users expose. Founders who run all three pass their first security review; the founders who run zero end up in our rescue queue.

FAQ

Are all 50 items mandatory?

12 are non-negotiable: RLS on every table, secrets out of the repo, error tracking, DB backups verified by restore, payment webhook signature verification and idempotency, env vars in a manager, SSL live on the custom domain, sitemap submitted, error-rate watch for 48 hours, and the 3 PII items (audit, access control, deletion path). The rest are strongly recommended — skip any one and it tends to bite within 90 days of launch.

Can I skip the email DNS items if I don't send email?

Yes, but almost every app sends at least transactional email — password resets, email verification, receipt emails from Stripe. SPF, DKIM, and DMARC affect deliverability; skip them and your auth emails land in spam. A password reset in spam is a churned user.

Why so many database items?

Database mistakes are the most common cause of post-launch incidents in AI-built apps. The widely-reported Lovable/Supabase RLS disclosure (summarized in our 2026 research) traced the incident to disabled Row Level Security. Backups missing or untested, indexes missing under load, and migration history not in the repo are the next three. Every item on this list ties to an incident we've seen in the rescue queue.

Do you have a downloadable PDF?

Coming soon. Email us if you want it now and we'll send it over. We also offer a fixed-fee 48-hour launch audit where we run the full 50-item checklist on your app and hand back a prioritised remediation list.

What breaks first if I skip the checklist?

In order, from our engagement data: (1) Stripe webhooks — Stripe's retries hit a non-idempotent handler and either double-charge or drop events. (2) Supabase RLS — a curl to the anon key returns everyone's rows. (3) Email deliverability — password resets land in spam. (4) Env vars — production reads a dev Supabase URL. (5) Error monitoring — you only find out the app is broken when a user emails. The 12 non-negotiables cover all five.

How long does a 50-item run take?

For a founder running it themselves: a full working day for audit, plus one to three days to fix whatever you find. For our team running it: 48 hours end-to-end with a written remediation plan on day three. The checklist is the fast part; the fixes are where the real time lives, and the fixes scale with how many items you skipped during the build.

Next step

Want us to run the checklist for you?

Book a launch audit. We'll run the full 50-item checklist on your app in 48 hours.

Book free diagnostic →