Production launch checklist

A deployed foundation is the starting point

Kickstart can provision the application foundation. Your launch additionally requires truthful product copy, working customer journeys, payment/email acceptance, privacy choices and recovery readiness. The prepared-account setup timing target is unmeasured and does not replace these checks.

Use this checklist against one identified release and one intended production target. Record evidence next to each item: command result, sanitized screenshot, inbox receipt, provider event or a reviewer note. A checkbox without a result is a reminder, not proof. Do not use the owner's installation or this manual's build as acceptance for a different buyer deployment.

Download the Markdown launch checklist for your private release record. Keep credentials, customer records and setup receipts out of the evidence you share publicly.

Product identity and public content

• Replace the starter's sample brand, positioning, navigation, footer, favicon and social image. Branding
• Describe only features your release actually implements; remove dead/demo purchase links. Public website
• Verify pricing copy matches the active catalog and Checkout selection. Plans
• Review blog examples, authors, thumbnails and draft/scheduled isolation. Blog publication
• Customize product docs and remove irrelevant example pages from the public collection. Documentation

Evidence: inspect desktop/mobile pages and both themes, follow public links, confirm the expected article and price in the running production app. A repository search for old brand text helps, but an intentional retained attribution may differ from unfinished copy.

Sender, authentication and invitations

• Production sender domain is verified; account-only onboarding sender restrictions are gone. Resend
• Fresh signup reaches the intended verification behavior and creates exactly the expected workspace. Authentication
• Login, logout, recovery and enabled magic-link flows work with actual inboxes.
• Google sign-in, if enabled, uses correct callback fields and succeeds in a real consent round trip.
• Invitation delivery and acceptance join only the invited workspace; expired/revoked/wrong-recipient links fail. Workspaces
• Contact form reaches the intended monitored inbox with correct reply-to behavior. Contact

Evidence: use authorized disposable accounts and recipients. Inspect the delivered link origin before following it. A provider's accepted-send status is not the same as inbox arrival. Record any verification-on or alternate-auth path you did not exercise.

Payments and subscription state

• Stripe account is activated for your intended live operation, with live key only in the production runtime. Stripe
• Test Checkout, actual payment event, webhook synchronization and workspace status agree. Subscriptions
• Portal changes, cancellation, failed/unpaid states and repeated events behave as documented.
• One workspace's subscription does not unlock another workspace; ordinary members cannot manage billing.
• Pending Checkout/nonterminal subscription deletion guards remain intact.
• Live acceptance is explicitly authorized and recorded before representing the product as ready to take payment.

Evidence: correlate the intended test/live mode, workspace, Checkout/subscription and resulting app state in a private record. Never expose a real customer's payment payload in a public screenshot. A completed catalog promotion is not a completed purchase.

Domains, deployment and runtime

• Vercel serves the expected Git commit on the verified HTTPS production domain. Deployment
• Auth redirects, email links and MCP audience agree with the active live origin. Origins
• Preview deployments remain disabled for the shared-origin setup.
• Production environment contains only the explicit runtime allowlist, with server credentials kept server-only.
• A subsequent Git change has been deployed through the ordinary update path. Updates
• Deployment protection and public ingress limits are appropriate for the product; logs redact authorization, cookies and token-bearing URLs.

Evidence: test public / and /login plus the authenticated dashboard. Inspect configured metadata without retrieving or publishing secret values. A READY deployment alone proves only the deployment state.

Tenant, role and integration checks

• Cross-workspace reads/writes and stale-member operations fail on the server/database. Testing
• Ownership transfer, last-owner protection, workspace/account deletion and billing guards pass.
• Avatar upload/access/remove and workspace-logo manager checks pass. Files
• Notifications/preferences and feedback privacy match the chosen behavior.
• API read-only writes, expired/revoked keys, quotas and deliberate extension grants pass. REST
• Enabled MCP client consent, tool invocation and revocation succeed against the deployed target. MCP
• Enabled AI handles history, Stop/Retry, provider failure and one-time credits correctly; removed AI leaves core journeys working. AI

Evidence: combine focused fixtures with real browser/provider tests. Document optional modules as disabled or untested when that is true. Do not count a skipped test as a pass.

Privacy, backup readiness and discovery

• Replace sample legal text and confirm it describes your real processing and retention. Legal samples
• Any added tracking actually respects the product's chosen consent behavior.
• Identify database backup availability/retention, Storage-object backup and protected setup-state recovery. Maintenance
• Rehearse recovery on an authorized separate target and record the data loss/downtime limits.
• Review titles, canonical origin, social image and truthful structured data. Metadata
• Enable indexing only after the above review; verify sitemap/robots and public-only Markdown exports. Discovery

Record the release decision

Write the release/source identifier, deployment commit, date, responsible reviewer and unresolved limitations. Keep source acquisition, support and license wording aligned with the terms actually supplied to buyers; this source snapshot does not establish a new support promise.

If a required path is blocked, keep it visibly pending in the private record and decide the product's supported scope accordingly. For this manual, the local site and text can be reviewed before target-specific screenshots and provider acceptance are complete. Publishing a fully verified release requires closing those material evidence gaps, not changing their labels.