Launch checklist

A product is sellable when every line below is true. Tick with evidence, not with confidence.

1. Legal and commercial (blocking)

• Privacy policy and terms are filled in: legal entity, commercial registration, address, privacy mailbox — the drafts in apps/marketing/content/legal/ mark every placeholder with [ ].
• A qualified lawyer has reviewed both, in both locales (*.md is Arabic, *.en.md English).
• The sub-processor table matches the providers actually configured in production.
• Pricing matches the code: packages/payments/config.ts (amounts), shared.json (pricing.products.* copy), capabilities.ts (what each plan unlocks) and PLAN_QUOTAS (how much) agree — four places, one truth.
• Refund and cancellation wording matches what the billing page actually does.
• The free tier is described as it behaves (engine-only, no time limit), not as a trial.
• A support mailbox exists and is monitored.

2. Money

• Payment provider is in live mode with live keys.
• One real subscription purchased end to end with the smallest plan.
• Webhook registered, secret set, and a signed webhook observed in the logs.
• Plan gating verified on a real account: a paid pattern unlocks, a locked one shows the upgrade path, and the API refuses it (the denial appears in the audit trail).
• VAT treatment confirmed with an accountant (15%, invoices, ZATCA requirements if you invoice).
• Payout bank account verified with the provider.

3. Reachability and messaging

• Sending domain verified; SPF, DKIM and DMARC published; MAIL_FROM on that domain.
• One real verification email and one real invitation received (not in spam).
• SMS sender id registered; phone OTP tested with a real number.
• Cookie consent banner blocks analytics until consent, and the choice is changeable.
• Legal pages are linked in the footer in both locales and open correctly.
• robots.txt and sitemap.xml reachable on the marketing origin.

4. Data and safety

• pnpm db:seed has never run against production; demo accounts do not exist there.
• Backups enabled and one restore tested.
• Retention implemented as documented (content 30 days after deletion, audit 12 months, usage 24 months, backups < 30 days).
• A deletion request can be honoured: account deletion removes the person's data, and the audit trail keeps only what the policy allows.
• Tenant isolation spot-checked: user B cannot read user A's workspace through the API.
• BETTER_AUTH_SECRET is unique to production and stored in a secret manager.
• Admin account created through pnpm --filter @repo/scripts create:user, with 2FA.

4b. Assistant access (if you sell it as a feature)

• At least one key created in production and stored in the customer's password manager.
• docs/mcp.md config verified against the deployed URL (not localhost).
• A revoked key really stops working, and the next request appears in the activity log.
• Read-only mode tested once with a client that does not need write access.

4c. Cloudflare deployment (blocking until the bundling step is fixed)

• pnpm build:worker completes and wrangler deploy --dry-run validates the bundle (37 MB upload, env.ASSETS binding). The pg-cloudflare export-condition mismatch is fixed by patches/[email protected]; see docs/deploy.md for when to drop it.
• wrangler whoami authenticated and CLOUDFLARE_ACCOUNT_ID set.
• Worker secrets set (DATABASE_URL, BETTER_AUTH_SECRET, and one per enabled feature).
• A Postgres provider reachable from Workers; Hyperdrive configured once the first deploy works.
• pnpm deploy:worker deployed to a staging worker, verified with the script, then promoted.

5. Operations

• /api/health and /api/health?deep=1 are wired to an uptime monitor.
• Alerts exist for 5xx rate and for a failed deployment.
• The release procedure in docs/deploy.md has been executed once, by the book.
• The verification script has been run against production and passed.
• A rollback has been rehearsed once (previous build redeployed).
• Someone is named as the incident contact, with a phone number that is answered.

6. Product quality

• pnpm format:check, lint, type-check, test, build are all green on the release commit.
• Every screen reads correctly in both locales with the NEXT_LOCALE cookie pinned.
• Mobile pass on a real phone: nav, boards, timer, dialogs.
• Keyboard pass: every board reachable and operable without a mouse.
• A new user can: sign up → create a workspace → write a task → run an agent → close a day, without reading documentation.
• Empty states name the next action; loading states are skeletons; a plan-locked surface explains what it would do.

7. Things this build does not have (say so, do not imply otherwise)

• No scheduled jobs: nothing sends a reminder on its own.
• No notification types beyond the two shipped ones; adding one is a deliberate change (enum + catalog + i18n together).
• No per-tenant custom domain, no public storefront, no mobile app.
• No team analytics beyond the daily team board.

If a claim in the marketing copy depends on one of these, remove the claim or build the feature before launch.