Pre-Launch Checklist

A build passing is one check. Before launching, use the app as a customer and record what worked, what failed, and what remains untested.

Code and first visit

• npm run lint, npm run typecheck, npm test, and npm run build pass for the version you are deploying.
• The deployed homepage loads on desktop and mobile, with working navigation and a clear next action.
• Your app name, metadata, prices, support contact, and legal pages match the real product.
• Required environment settings are present; NEXT_PUBLIC_APP_URL uses the correct HTTPS domain.
• No private keys, local settings files, or customer data are staged in Git or exposed in the browser.

Sign-in and your core feature

• A new user can receive a magic link and reach the dashboard. Supabase custom SMTP is configured for real users.
• Sign out and sign in again work; expired/reused links produce useful guidance.
• Logged-out users cannot call protected actions or APIs directly.
• Two separate accounts can each use your main feature without seeing or modifying each other's data.
• Empty input, invalid input, no data, and a provider failure produce useful feedback.
• New database changes are saved in SQL files and applied to the deployed database.

Subscriptions, if you charge

Complete the Stripe sandbox flow first. Use test keys and Stripe test cards, not real cards or live discount coupons.

• A real checkout through your test app reaches Stripe and returns to the app.
• The webhook receives the event and updates the correct user's subscription in Supabase.
• Reaching a success URL without payment does not unlock paid features.
• The correct plan appears in settings and the customer portal opens.
• Cancellation and failed-payment behavior match your stated access policy.
• Paid-feature access is enforced on the server, including direct API requests.
• The production launch uses matching live keys, live prices, live portal settings, and a reachable live webhook with its own signing secret.

Email, AI, and operations

• Transactional emails you actually trigger arrive from your verified domain; failures are visible in provider logs.
• AI/API features have input limits, appropriate per-user usage limits, and a provider spending limit.
• Scheduled tasks are authenticated and safe to retry; third-party failures do not silently lose work.
• You know where to check deploy logs, Stripe deliveries, Supabase logs, and email failures.
• You have a Git checkpoint and understand your database backup/restore options.

Skip optional-service checks only when the app does not use that service. Mark untested items explicitly instead of treating them as passed.

Ask your agent to help review

Review this app against AGENTS.md and docs/deploying/checklist.md.
The current online guide is https://getghoststack.dev/docs/deploying/checklist.
If neither version is accessible, ask me to paste it rather than assuming you read it.
Run the relevant local checks. Inspect the code for missing authentication,
ownership checks, input limits, and configuration. Use authorized development
service tools where available without exposing secrets or customer data.
Report: passed with evidence, failed, and not tested. Do not claim that a live
payment, email, or deployment worked unless that flow was actually observed.

Before buying traffic, confirm the landing page describes the product accurately, support links work, and a completed purchase is distinguishable from a button click in your chosen measurement setup.