Most launch checklists are written from inside the product: remove test data, confirm billing, turn on analytics, and prepare support.
Those steps matter. They miss the public surface: the pages, responses, claims, and journeys that shape a stranger’s first independent judgment.
A launch is ready when the important promise survives without the founder in the room.
1. Explain the product in one pass
A visitor should be able to identify what the product does, who it is for, and what happens next without assembling the answer from navigation labels.
Give the homepage one descriptive title, one clear primary heading, a useful explanation, and an explicit action. Replace category slogans with an input and result. “Upload a contract and receive a clause-by-clause risk summary” gives the reader something to picture. “The intelligence layer for modern legal work” does not.
Ask five people in the intended audience to view the opening screen briefly. Then ask what the product does and what they would click. Wrong answers are evidence, not a reason to explain the copy aloud.
For a deeper test, use the guide to startup homepage clarity.
2. Make the operator visible
Before users create an account or pay, they look for accountability. Publish a real contact path, privacy policy, terms, and an about page. Use the same brand and operating-company names across the site, checkout, receipts, and policies.
These pages do not need to be long. They need to be findable, specific, and true of the product that exists today.
Test the support address from outside the company. Confirm that the message arrives, a person owns the inbox, and replies use an identity the customer recognizes.
3. Complete the core journey from a clean account
Founders test the route they remember. New users take the route the interface suggests.
Use a device, browser profile, and email address that have never touched the product. Start at the public homepage and complete the main job. Do not use an administrator account. Do not repair data from the database.
Test:
- Signup, verification, sign-in, sign-out, and recovery.
- The first useful action with realistic input.
- Payment, receipt, cancellation, and refund when relevant.
- Return to the saved result from another device.
- Export or deletion when the product promises it.
Watch another person do the same while you remain silent. Every explanation you want to give is missing product work. The guide to fixing the product’s first minute helps isolate early friction.
4. Test production email as part of the interface
A successful response from an email API does not prove delivery.
Send verification, recovery, invitation, receipt, and alert messages to several real mailbox providers. Check delay, spam placement, sender identity, mobile layout, reply behavior, link expiry, and what happens when the link is opened twice.
Verify the sending domain and live DNS configuration. Handle bounces and provider failures. Preserve the user’s work across the trip to the inbox. The transactional email checklist covers this path in detail.
5. Exercise the failures
The happy path is only one state of the product.
Try an existing email, wrong password, expired link, declined card, duplicate click, unsupported file, oversized input, missing permission, dropped connection, provider timeout, and empty result.
An error should say what failed, whether work was saved, and what the user can do. A retry should be safe. A support route should exist when the product cannot recover automatically.
Test at a phone-sized viewport, at 200% text zoom, and with a keyboard. Check loading, empty, error, and success states, not only the polished screen with sample data.
6. Review identity, money, and data boundaries
Create two ordinary accounts. Try to read or change one account’s records from the other. Hiding a button is not authorization; the server must enforce ownership on every protected action.
Submit important operations twice. Payments, invitations, webhooks, and destructive actions should not produce duplicate consequences.
Confirm that secrets stay on the server and private data does not enter URLs, analytics, browser bundles, or logs. Create, export, delete, and restore a realistic record. “Backups enabled” is a setting. A successful restoration is evidence.
Use the production checklist for an AI-built app when generated code handles these paths.
7. Check the public delivery layer
Open the production hostname over HTTP and HTTPS. Confirm that all variants redirect to one secure canonical address. Test the apex and www hostnames, important subdomains, and old launch URLs.
Remove mixed content. Set secure cookie attributes. Prevent unintended framing. Add transport protection only when the HTTPS estate and subdomains are ready for it. Deploy a considered Content Security Policy rather than copying one that silently breaks the product.
The security headers before launch guide explains how to test those browser boundaries without chasing a scanner grade.
Trigger one production error on purpose. Confirm that it reaches a person with enough context to act and without leaking sensitive data.
8. Give search systems a coherent source
Important pages need stable URLs, descriptive server-rendered text, canonical metadata, crawlable links, and inclusion in the XML sitemap. Review robots.txt, page-level robots directives, and canonical tags together.
When a launched page remains absent from search, follow the new-site indexing diagnosis one stage at a time.
Do not place staging pages, private reports, internal search results, or duplicate routes in the sitemap. Do not use robots.txt as a privacy control; private information needs authentication.
Add structured data only when it describes visible content. Keep product name, price, capabilities, company identity, and status consistent across the homepage, docs, policies, metadata, and third-party profiles.
9. Read every public claim side by side
Compare the homepage, pricing, documentation, terms, onboarding, product UI, emails, and launch post in one sitting.
Look for old plan names, contradictory limits, dead waitlist language, unavailable integrations, fake urgency, and policies that describe services no longer used. A founder knows stale copy is accidental. A first-time visitor cannot.
If a claim cannot be checked, narrow it. Replace “completely secure” with the specific control and its scope. Replace “instant” with a measured range. Replace “trusted by teams” with evidence or silence.
10. Prepare the stop button
Decide who owns the launch and which failures stop it. Privacy exposure, duplicate charges, corrupted data, runaway cost, and widespread failure of the core journey should not compete with cosmetic defects for attention.
Know the last safe release. Rehearse a rollback or safe feature shutdown. Keep a timestamped record of changes during the launch. The small-startup launch runbook provides a compact structure.
Prioritize by consequence
A missing social image should not outrank a broken signup. A crooked icon should not outrank a receipt that never arrives.
Classify findings by what they can prevent: understanding, trust, access, payment, safety, recovery, or discovery. Fix the blockers. Deploy. Repeat the outside-in journey.
The checklist is not the finish line. The live product is the test.