Web DevelopmentCanvasDevs TeamUpdated

A Production Checklist for Next.js App Router Sites

A practical launch review for an existing Next.js application: consistent rendering, access control, metadata, integrations, deployment and handover.

Back to blog3 min read
A Production Checklist for Next.js App Router Sites
3 min read3 min left

Start with the application you have

A working preview is a useful starting point. Before accepting payments or inviting customers, list the journeys that must work outside the happy path. For an AI-built SaaS app, that might mean signing up, joining the correct workspace, paying, recovering access and cancelling a subscription. Keep useful code; assess missing behavior before deciding whether anything needs rebuilding.

For an unfamiliar codebase, a scoped paid assessment should produce a reproducible local setup, a prioritized issue list and a completion plan. Provide repository access, a test environment, a description of user roles and the intended release scope. Share credentials through an agreed secure channel.

Make the server and first browser render agree

React expects the initial client output to match the server HTML. Avoid computing different values with Date.now(), random identifiers or browser-only storage during that first render. For a date, send a stable timestamp and use the same locale and time zone on both sides. If a browser preference must change the display, apply it after hydration without moving important content.

suppressHydrationWarning is a limited escape hatch for an unavoidable difference on one element. It works one level deep, and React does not repair mismatched text through it. It is not a general repair for incorrect rendering or browser extensions. Reproduce the cause before choosing the fix. See React's hydration reference.

Choose metadata appropriate to the route

Use a static metadata export when a title and description are fixed. Use generateMetadata when they depend on route parameters or fetched content. Every route does not need its own function; layouts can provide shared defaults. Verify the resolved title, description, canonical and sharing image in the delivered response. The Next.js metadata reference explains both approaches.

Test boundaries, not just screens

  • Access: a signed-out user cannot read private data, and one workspace cannot read another workspace's records. Check server authorization even when buttons are hidden.
  • Integrations: exercise declined payments, delayed webhooks, duplicate events and expired credentials in a sandbox. A successful redirect alone should not grant paid access.
  • Data: document which responses can be cached, what invalidates them, and how a user's private data stays out of shared caches. Verify the behavior against the installed Next.js version.
  • Forms: preserve input after failure, show understandable errors and prevent duplicate submissions. Test with a keyboard and at narrow widths.
  • Release: verify environment variables, migrations, backups, monitoring and a workable rollback. Decide who can deploy and who responds to failures.

Example acceptance check

For a subscription dashboard, create two test accounts in separate workspaces. Cancel payment for the first, complete a sandbox payment for the second, and replay the second payment notification. Confirm that only the paid workspace receives access and that the replay creates no duplicate entitlement. Record the result and any unresolved limitation in the release checklist.

Measure loading and layout stability before optimizing, then repeat the same scenario after a change. A laboratory test helps diagnose a problem; it does not establish real-user Core Web Vitals percentiles.

Canvas Developers offers AI app completion and web application development. The first step is understanding the current application and agreeing what a launch-ready release includes.