Launch Readiness Checklist

Use this page when a workspace is close to launch, relaunch, domain cutover, paid-flow enablement, booking enablement, or major integration change.

Launch Decision

A workspace is ready for live traffic when:

• The public site accurately represents the business.
• The primary customer action works.
• Payments are connected if money is collected.
• Notifications reach the right recipients.
• Operators know where incoming work appears.
• Legal, consent, and email settings match the configured integrations.

Decide launch status with evidence, not confidence. A launch packet should name the workspace, launch owner, launch date, public URL, enabled customer actions, payment posture, integration posture, known risks, and rollback owner. If one critical customer path is not ready, launch a narrower experience instead of pushing the full workspace live.

Required Checks

Readiness Score

Score each launch area from 0 to 3. The goal is not a vanity number; it is a shared way to decide what can ship and what must wait.

Minimum launch standard:

• Primary customer action: 3.
• Payments, if enabled: 3.
• Domain and sender identity: 2 or 3.
• Notifications: 2 or 3.
• Legal and consent: 2 or 3.
• Operations ownership: 3.

If the primary customer action is commerce, checkout must be the primary score. If the primary customer action is bookings, service availability and confirmation must be the primary score. If the site is content-first, navigation, contact, search previews, and inbox ownership become the primary score.

Risk Levels

Use these levels to decide whether a finding blocks launch:

Every Critical or High issue needs an owner, mitigation, and retest note. Do not bury launch blockers in a general task list.

Payment Readiness

Do not launch paid flows until:

1. Stripe account is connected.
2. Requirements and payouts are understood.
3. Product checkout or booking payment is tested.
4. Refund and cancellation behavior is understood.
5. Taxes and shipping are intentional.
6. Notification emails are correct.

Payment scoring details:

If payments are not ready, launch content and inquiry flows only. Hide paid products, disable checkout, or keep booking deposits disabled until the payment path is tested.

Booking Readiness

Do not launch booking flows until:

1. Services are visible.
2. Availability shows real times.
3. Staff and calendar sync are correct.
4. Deposits or final payment rules are correct.
5. Confirmation and reschedule paths work.
6. Operators know how to amend, cancel, no-show, complete, and refund.

Booking scoring details:

If booking readiness is mixed, launch only the ready services. Hide services with uncertain capacity, missing staff assignment, or unclear pricing.

Site Readiness

Do not launch public traffic until:

1. Homepage and navigation are complete.
2. Legal pages are reachable.
3. Contact path is monitored.
4. Search previews are acceptable.
5. Mobile layout is checked.
6. Custom domain works.

Site scoring details:

Use a protected or preview-only state when content is not ready but operators still need to verify configuration.

Integration Readiness

Only enable integrations that have an owner:

• GA4: Measurement ID valid and consent posture understood.
• Google Ads: Conversion ID valid, conversion label configured if explicit event tracking is needed, legal acknowledgements complete.
• Google Business Profile: connection status healthy and review sync expectations clear.
• Calendar: connected provider and conflict behavior tested.
• Shipping: origin, packages, zones, rates, labels, and tracking tested.

Integration scoring details:

If an integration is useful but not ready, disable it and record the exact missing evidence. A disabled integration with a clear owner is safer than an enabled integration nobody can support.

Launch Packet

Before moving a workspace into live traffic, write a short packet with:

• Workspace name and slug.
• Public URL and launch date.
• Launch owner and backup owner.
• Primary customer action.
• Enabled features.
• Disabled or intentionally hidden features.
• Readiness score by area.
• Critical and High issues with mitigations.
• Rollback steps.
• Post-launch watch owner and check times.

The packet should be short enough to read in a handoff, but specific enough that another operator can tell what was launched and what was deferred.

Rollback And Narrow Launch

Prefer narrow rollback over taking down the whole site. Examples:

After rollback, retest the exact failed path before re-enabling it. Do not relaunch based only on a config change.

Post-Launch Watch

For the first day after launch, watch:

• Insights.
• Sales.
• Scheduling.
• Payments.
• Shipping.
• Inbox.
• Customers.
• Error reports.
• Public site conversion paths.

If a critical path fails, pause the narrow path first: disable checkout, set a site to protected, pause ads, or hide a feature while preserving the rest of the workspace when possible.

Relaunch Triggers

Run this checklist again when:

• A custom domain changes.
• Checkout, tax, Stripe Connect, PayPal, or shipping changes.
• New booking services, staff, deposits, or calendar sync are introduced.
• Google Ads, GA4, or consent settings change.
• A workspace adds customer portal, tickets, billing, or subscriptions.
• Legal, policy, sender identity, or notification templates change.
• A major content migration, template migration, or rebrand ships.

Treat relaunches as smaller launches. The work is lighter, but the customer risk can be just as real.