Skip to main content
Back to Blog
4 min read

The 23-item pre-launch checklist I run before every client go-live

Every client project gets this checklist before launch. 23 items across security, performance, SEO, monitoring, and legal. Most take 5 minutes. Together they prevent 90% of post-launch fires.

performancesecurity

Every project I ship gets the same checklist before go-live. It takes 2–3 hours to run through. It's caught issues on every single project — no exceptions.

Here are all 23 items, in the order I run them.

Security (items 1–6)

  1. Environment variables are not in the client bundle. Search the built JS for your API keys. If they appear, you have a leak. Only NEXT_PUBLIC_* vars should be client-visible.

  2. Auth tokens expire. Infinite-lived tokens are the most common security issue I find. Session tokens should expire in 24h–7d. Refresh tokens in 30d max.

  3. Rate limiting on auth endpoints. Login, signup, password reset — all must have rate limits. 5 attempts per minute per IP is a reasonable default.

  4. CORS is configured correctly. Access-Control-Allow-Origin: * in production is a vulnerability. Whitelist your specific domains.

  5. No secrets in git history. Run git log --all -p | grep -i "sk_live\|secret\|password\|token" on the repo. If secrets were ever committed, rotate them — deleting from history isn't enough.

  6. CSP headers are set. Content Security Policy prevents XSS attacks. At minimum: default-src 'self' with explicit exceptions for your CDN, analytics, and fonts.

Performance (items 7–12)

  1. Lighthouse score above 90 on mobile. Run against the production URL, not localhost. I wrote about hitting 98 — the baseline should be 90+.

  2. Images are optimized. WebP or AVIF format. Proper width/height attributes. Only the hero image has priority. Check with: no image larger than 200KB on initial load.

  3. Fonts are self-hosted. No Google Fonts links. WOFF2 format with font-display: swap. This prevents the Lighthouse drop I debugged.

  4. No render-blocking resources. Check the Lighthouse "Eliminate render-blocking resources" audit. Move non-critical CSS/JS to async loading.

  5. Error pages return correct status codes. curl -I yoursite.com/nonexistent should return 404, not 200. Soft 404s cause SEO issues.

  6. API response times under 500ms (p95). Check Vercel analytics or your monitoring tool. Any endpoint above 500ms needs investigation.

SEO (items 13–17)

  1. Sitemap exists and returns XML. curl -s yoursite.com/sitemap.xml | head -5 should show XML, not HTML. This is a real bug I've caught.

  2. robots.txt is correct. Should allow / and point to your sitemap. No accidental blocks on /api/ or /_next/static/.

  3. Every page has unique title and meta description. No two pages should share the same title. Descriptions should be under 155 characters and include the primary keyword.

  4. hreflang tags for multilingual sites. Each page lists all its language alternatives. Test with: Google Search Console → URL Inspection.

  5. Structured data validates. Test JSON-LD with Google's Rich Results Test. Common issues: missing datePublished, invalid author schema.

Monitoring (items 18–20)

  1. Error tracking is configured. Sentry with noise filtering or equivalent. Alert on new issues in payment and auth flows.

  2. Uptime monitoring is active. External ping (UptimeRobot, Better Stack) checking the homepage and at least one API endpoint every 5 minutes.

  3. Analytics is collecting data. Verify events are flowing: visit the site, check your analytics dashboard 5 minutes later. Cookie-free analytics (Plausible) avoids consent issues.

Legal & compliance (items 21–22)

  1. Privacy policy is published and linked from the footer. Covers what you collect, why, who you share with, and how to request deletion. GDPR setup guide.

  2. Cookie consent (if needed). Only if you use cookies for analytics. If using Plausible or PostHog cookie-free mode, this isn't needed.

Final (item 23)

  1. Buy your own product. If there's a payment flow, buy something with a real card. This single test catches more integration issues than 50 automated tests. I learned this the hard way.

How I use this list

I run through it on the staging environment 2 days before launch. Items that fail get fixed on day 1. Day 2 is a re-run of failed items plus a full manual walkthrough of the core user flow.

On launch day, I run items 13, 18, 19, 20, and 23 again on the production URL. These are the ones most likely to break during the staging → production transition.

The whole process: 2–3 hours for the initial run, 1 hour for the launch-day re-check. Compare that to the 20+ hours I've spent debugging post-launch fires that any of these items would have caught.

Want this checklist run on your project before launch? Let's talk — I run this on every client go-live, and it's saved every one of them from at least one post-launch incident.