VIKAS

Posted on Apr 12

My Pre-Launch Checklist Before Handing Off Any Client We

#nextjs #webdev #javascript #productivity

After shipping 10+ web apps for founders and SMEs, I've noticed something.

Most post-launch fires aren't technical failures. They're checklist failures. Things nobody caught because everyone assumed someone else did.

This is the exact list I run through before every client handoff at Zyklabs. Some of these take 5 minutes. Some take an hour. All of them have saved me at least once.

1. Environment and Config Hygiene

The number one source of "works on my machine" disasters.

[ ] All .env variables documented in ENV_SCHEMA.md
[ ] No hardcoded API keys, secrets, or base URLs anywhere in the codebase
[ ] NODE_ENV=production confirmed in deployment settings
[ ] Separate env files for staging vs production
[ ] Secrets stored in the platform vault (Vercel, Railway, etc.), not in the repo

Real case: Found Razorpay test keys going live on a production deployment. No transactions processed, but it could have. Caught it on this exact step.

2. Performance Baseline

You need numbers before handoff. Not a feeling that it seems fast.

[ ] Lighthouse Performance score above 85
[ ] LCP (Largest Contentful Paint) under 2.5s
[ ] No render-blocking scripts in <head>
[ ] Images converted to WebP, using next/image with correct sizes prop
[ ] Fonts loaded via next/font or preloaded to avoid layout shift (CLS under 0.1)
[ ] Bundle analyzer run, no accidental heavy imports

# Quick audit options
npx @next/bundle-analyzer
npx unlighthouse --site https://yourclientsite.com

3. SEO Minimum Viable Setup

Google crawls on Day 1 whether you're ready or not.

[ ] Unique <title> and <meta description> on every page
[ ] robots.txt not accidentally blocking crawlers
[ ] sitemap.xml generated and submitted to Search Console
[ ] OG tags set: og:image, og:title, og:description
[ ] Canonical URLs configured to avoid duplicate content issues
[ ] No broken internal links (run broken-link-checker before pushing)

For Next.js App Router projects:

// app/layout.tsx
export const metadata = {
  title: 'Client App | Brand Name',
  description: 'Clear description under 155 characters with primary keyword.',
  openGraph: {
    images: ['/og-image.jpg'],
  },
}

4. Security Headers

30 minutes of config work. Prevents a class of embarrassing vulnerabilities.

[ ] Content-Security-Policy header set
[ ] X-Frame-Options: DENY (prevents clickjacking)
[ ] X-Content-Type-Options: nosniff
[ ] Strict-Transport-Security (HSTS) enabled
[ ] HTTPS enforced, no HTTP fallback
[ ] Admin routes protected at middleware level, not just the frontend

// next.config.js
const securityHeaders = [
  { key: 'X-Frame-Options', value: 'DENY' },
  { key: 'X-Content-Type-Options', value: 'nosniff' },
  {
    key: 'Strict-Transport-Security',
    value: 'max-age=63072000; includeSubDomains; preload',
  },
]

5. Email and Transactional Flows

Test every email. Every single one. Don't assume.

[ ] Signup confirmation hits inbox, not spam
[ ] Password reset flow works end-to-end in production
[ ] Order/booking confirmation tested with real data
[ ] SPF, DKIM, DMARC records set on the sending domain
[ ] "From" address is domain-based (not @gmail.com)
[ ] Email footer includes unsubscribe link and physical address

Tool: Use mail-tester.com before going live. Score of 9+/10 is the target. Anything below 7 and you're probably landing in spam.

6. Error Tracking and Monitoring

You can't fix what you can't see in production.

[ ] Sentry (or equivalent) initialized and sending events
[ ] Source maps uploaded so stack traces are readable
[ ] Custom 500 error page, not the default framework page
[ ] Custom 404 page with navigation back to home
[ ] API errors return correct HTTP status codes (not 200 with an error body)
[ ] Uptime monitor set up (UptimeRobot free tier covers this fine)

7. Database and Data Safety

The one category people rush through because they're excited to ship.

[ ] Backups enabled, and restore has been tested (not just backup)
[ ] No direct DB access from the frontend, always through the API layer
[ ] Server-side input validation on all user-facing fields
[ ] Indexes on all queried fields
[ ] Rate limiting on auth endpoints: login, signup, password reset

Backup you've never tested is not a backup. Restore it once in staging before launch.

8. Cross-Device QA

Done is not done until it works on a real phone.

[ ] Tested on an actual mobile device, not just browser devtools
[ ] All forms work on iOS Safari (it has specific input quirks)
[ ] Touch targets are at least 44px
[ ] No horizontal scroll on mobile viewports
[ ] Loading states exist for every async action

9. Handoff Documentation

This is what separates a studio from a one-off freelancer job.

[ ] README.md covers: local setup, env variables, deployment steps
[ ] Architecture diagram included (even a rough one)
[ ] Credentials stored in a password manager, not sent over email or Notion
[ ] Domain, hosting, and third-party service access transferred to client
[ ] Post-launch support window communicated and agreed on in writing

The Full Scorecard

Category	Items	Approx Time
Env and Config	5	15 min
Performance	6	30 min
SEO	6	20 min
Security Headers	6	30 min
Email Flows	6	45 min
Error Tracking	6	20 min
Database	5	20 min
Cross-Device QA	5	30 min
Documentation	5	60 min
Total	50 items	~4 hours

Four hours before launch. That's it.

Most teams skip this and spend four days firefighting after launch instead. The math is pretty obvious.

The difference between a client who refers you to three others and one who quietly never calls back often comes down to what you caught before they did.

Run the checklist. Every time.

We run this on every project at Zyklabs, a web dev studio building MVPs, SaaS platforms, and storefronts for founders and SMEs across India. If you're building something and want a team that sweats the details, reach out. 🙌

DEV Community