--- slug: vibe-coded-app-launch-checklist title: "Pre-Launch Checklist for a Vibe-Coded App" excerpt: "An app launch checklist for vibe-coded apps. The auth, billing, legal, and ops bits the AI didn't add for you, with sensible defaults for each." primaryKeyword: "app launch checklist" publishedAt: 2026-04-18 readingTimeMin: 8 author: "Robert Boylan" tags: - app-launch - shipping - vibe-coding - indie-dev - launch-checklist --- The app works on your laptop. It works on staging. You've shown three friends and they've clicked around without anything obviously breaking. You're a day from launch and there's a quiet question you're trying not to ask: am I forgetting something? You probably are. Not because you're careless, but because vibe-coded apps systematically miss the same set of operational pieces. The AI built the parts you described. It didn't build the parts you didn't think to describe, and "the parts nobody thinks to describe" is exactly what the launch checklist is for. Here's the version that catches the misses without padding the list with consultancy filler. ## Auth: real reset, real expiry, real lockout Almost every vibe-coded app has signup and login. Almost none have everything underneath those two flows actually working. Things to check: - **Password reset.** Does the email actually send? Does the reset link expire? Does it invalidate after one use? AI tools generate the happy path; the security bits often quietly don't work. - **Session expiry.** How long does a logged-in session last? What happens when it expires? Does the user get bounced cleanly to login or do they hit a confusing 401? - **Logout.** Yes, really. In some Lovable and v0 apps the logout button calls a stub function that doesn't actually clear the session. - **Account deletion.** If your privacy policy promises users can delete their account (and post-GDPR, it should), there has to be a button somewhere that actually deletes it. Test all four with a throwaway email before launch. The bug you find is always less embarrassing in a test than in a launch-day Reddit thread. ## Billing: live keys, refund flow, tax If you're charging anything, billing is the most common source of launch-day disasters. Two-thirds of "we had to roll back" stories trace back here. Mandatory before launch: - **Live mode keys are deployed.** It's astonishingly common to launch with test keys still in production, take payments that never settle, and discover this five customers in. - **Webhooks are signed and verified.** Without signature verification, anyone can hit your webhook endpoint and forge payment events. - **Refund flow exists.** Not the policy, the mechanism. Can you actually refund a customer in under five minutes when they ask? If the answer involves SQL, that's not good enough. - **Tax is handled.** Stripe Tax, Lemon Squeezy, Paddle, Polar. Pick one and turn it on. Selling to EU customers without VAT handling is illegal, not just inconvenient. There's a longer write-up on [what AI coding tools get wrong about Stripe integrations](/blog/add-stripe-to-vibe-coded-app) if you're still wiring this up. The short version: assume the AI generated checkout-only and you need to fill in the rest. ## Legal: privacy, terms, cookies Three documents. Not optional. Not "I'll add them next week." - **Privacy policy.** Even if you don't think you collect personal data, you almost certainly do (email, IP address, anything an analytics tool sees). The policy must accurately describe what you collect, why, and how to delete it. - **Terms of service.** What users agree to by using the app. Liability limits, acceptable use, what happens if you shut down. - **Cookie banner (if EU traffic).** GDPR-compliant cookie consent if you serve any EU users, which you do, even if you didn't intend to. There are services that generate these for solo founders (Termly, iubenda, Termageddon). There are also AI tools that will write them, which is fine for a first draft but absolutely not a substitute for a quick read by a human who knows the jurisdiction. Don't ship boilerplate that promises features you don't have. The privacy policy that says "users can request deletion" needs to come with a button that actually deletes the account. ## Operational: errors, uptime, backups You will not be watching the app at 3am. Something will break. Three things make the difference between "fix it in five minutes" and "find out three days later from a refund-asking customer". - **Error tracking.** Sentry, LogRocket, or similar wired into the frontend and backend. When a user hits a 500, you should know within seconds, not when they tweet about it. - **Uptime monitoring.** Better Stack, UptimeRobot, or even a simple cron-pinged endpoint. If the app is down, your phone should buzz. - **Database backups.** Most managed Postgres providers (Supabase, Neon, Render) have automated backups; check that yours is actually on, not just available. Restore one to a staging environment as a real test, not just an admin-panel checkbox. These three together cost about $0 to $20 a month for an indie app. The cost of not having them is one bad weekend. ## Marketing: the bits search engines and shares actually need The app is built. People will (hopefully) link to it, share it in Slack, find it on Google. Three things make the difference between a respectable share preview and one that looks broken. - **OG image.** A 1200×630 image at `og:image` so the link preview on Twitter/X, Slack, and LinkedIn shows your app, not a default browser thumbnail. Generate one in Figma in twenty minutes; you don't need a designer. - **Sitemap.** A sitemap.xml at the root telling search engines what URLs you have and when they last changed. Auto-generate it from your routes. - **Analytics.** Plausible, PostHog, or whatever you prefer, on day one. Without analytics you can't tell if the launch went well or if you got 12 visitors. Don't fly blind. ## Support: a real email and an actual reply plan Last one. Nobody talks about it. It's the difference between a launch that builds trust and one that builds churn. - **A real support email** that goes somewhere you actually check. `support@yourdomain.com` forwarded to a real inbox, not a generic info@ that nobody monitors. - **An auto-responder** that sets expectations. "Thanks, we usually reply within a day" is honest if true. Silence is corrosive. - **A reply plan.** Who replies? When? What's the canned answer for the three most common questions you've already heard from beta users? This is also where you find out whether the app is solving a real problem. The first ten support emails are gold. Read them, don't just close them. ## What's not on this list (and why) A lot of pre-launch checklists you'll find online include things like "load testing", "CDN configuration", "feature flags", "internationalisation", "accessibility audit". For a vibe-coded indie app, those are mostly premature. You don't need a CDN until you have traffic. You don't need feature flags until you have a team. You don't need to support twelve languages until customers in those countries are paying you. Premature optimisation is its own way of never shipping. The list above is the floor, not the ceiling. Hit all of it and you've crossed the threshold from "weekend project" to "small business asset." Skip half of it and you've shipped something that will eat one of your nights in the next month. ## Where the spec helps Every item on this checklist is a thing the AI wouldn't have built unless you described it. That's not a criticism of the AI; it's how AI coding tools work. They build what's in the spec, and skip what isn't. If the launch checklist feels long now, picture how long it would be if the AI had also forgotten the auth flow, the billing model, and the data structure. Most of these items become trivial when they're in the spec from the start. Account deletion is a checkbox question. Refund flow is a one-line decision. Cookie banner is a single field. The reason this checklist feels heavy is that you're hitting all these decisions at once, the day before launch, instead of weeks earlier when they were cheap. That's the actual case for [a spec that captures the operational decisions upfront](/blog/inside-an-exported-prd). The launch checklist still exists, but it shrinks from "everything I forgot" to "let me verify the things I already decided." You stop launching against a list of mysteries and start launching against a list of confirmations. The product looks the same to users either way; the version of you doing the launch is much less stressed.