A successful next build proves that the application compiles. It does not prove that the product is ready for real users, crawlers, traffic spikes, or a difficult incident.

Rendering and caching#

Confirm the rendering strategy for every important route. Static content should not become dynamic because a convenience API reads request state. Dynamic pages need explicit cache behaviour, and revalidation should match how quickly the underlying data can change. Test authenticated and anonymous paths separately.

Measure real pages on realistic devices. Optimise the largest content element, reserve space for media, load fonts deliberately, and keep client-side JavaScript under control. A server component is useful when it meaningfully reduces browser work—not merely because it is the default.

Security and data#

Validate all input at the server boundary. Check authorisation at the data operation, not only in middleware or UI. Use secure cookie settings, restrictive content security policy, rate limits for expensive actions, and scoped credentials for every environment. Ensure source maps and logs cannot expose secrets or personal data.

Exercise failure paths for payments, webhooks, uploads, and third-party APIs. Webhooks need signature verification and idempotency. Background work needs retries with limits, visibility into failed jobs, and a way to replay them safely.

Search and accessibility#

Every public page needs a deliberate title, description, canonical URL, sharing metadata, and valid heading structure. Generate a sitemap, configure robots rules, and verify structured data. Navigate core journeys with a keyboard and screen reader; test focus, errors, reduced motion, contrast, and zoom.

Operations#

Capture errors with release identifiers and enough context to act. Add health checks, uptime monitoring, performance telemetry, and alerts tied to user impact. Document deployment, rollback, database migration, and incident ownership.

Finally, run a release rehearsal from a clean environment. The best checklist is not a document that says “done”; it is evidence that the system can be deployed, observed, recovered, and understood by someone other than its author.