Production checklist

Before deployment

• Run type checking, linting, tests, and a production build in CI.
• Validate required environment configuration.
• Keep secrets server-only.
• Review large Client Component boundaries.
• Check for obvious sequential data waterfalls.
• Add loading, empty, error, and not-found states.
• Confirm protected operations enforce authorisation on the server.
• Check image dimensions and likely LCP resources.
• Review third-party scripts.
• Make important public routes reachable through internal links.

Search and sharing

• Verify canonical URLs on the real domain.
• Check robots.txt and sitemap.xml.
• Give important routes unique titles and descriptions.
• Test Open Graph images with absolute production URLs.
• Use structured data only when it matches visible content.
• Redirect retired URLs permanently where appropriate.

After deployment

• Open the site from a clean browser session.
• Inspect production response headers.
• Verify authentication and permission boundaries.
• Exercise one real mutation end to end.
• Check error reporting.
• Watch Web Vitals and slow requests.
• Confirm caching and revalidation behave the way the product expects.
• Test mobile navigation and keyboard navigation.

Prefer architecture you can explain

The best setup is rarely the one using the most Next.js features. It is the one where the next developer can tell what runs on the server, what reaches the browser, how fresh the data is, who may change it, and what happens when it fails.

If those answers are obvious from the code, the architecture is doing its job.

Deployments need a way back

A green build proves that the code compiled. It does not prove that production data, environment variables, third-party services, and real traffic will behave exactly as expected. Decide how to roll back before pressing deploy.

For database changes, prefer migrations that are compatible with both the old and new application for a short period. Add a nullable column before requiring it, deploy code that can handle both shapes, backfill the data, and only then tighten the constraint. This avoids turning a code rollback into a database emergency.

• Keep the previous healthy deployment available.
• Write down which changes cannot be rolled back safely.
• Use feature flags for risky behaviour changes when possible.
• Separate deployment success from feature release.
• Test the rollback path occasionally, not during the first incident.

Run a small, real production smoke test

A useful smoke test follows one important journey with production URLs and production configuration. Sign in, load protected data, submit a harmless mutation, refresh the result, and sign out. That short path catches missing cookies, incorrect callback URLs, broken cache invalidation, and absent environment variables better than checking the home page alone.

Keep this test small enough that a person can run it after an urgent release. Automate it later, but first make sure the steps describe what healthy actually means for the product.