Next.js in Production: The Parts the Tutorial Skips

Next.js is the framework I reach for most on the web, and it's genuinely excellent. It's also a framework where the gap between "works in the tutorial" and "works for a team shipping to real users" is wide and quiet. Here's where that gap tends to open.

Rendering strategy is an architecture decision, not a default

Server components, client components, static, streaming, ISR — the choice isn't cosmetic. Get it wrong and you ship either a slow first paint or a hydration mess. The discipline is deciding, per route, what actually needs to be dynamic and pushing everything else to the edge or to build time. Most pages need far less client JavaScript than they ship.

The data-fetching boundary is where teams hurt themselves

Fetching in the wrong place — waterfalls of awaits, client fetches that should have been server, caching that's either too aggressive or absent — is the most common production problem I see. Decide deliberately where data is fetched and cached, and make it a convention the whole team follows, not a per-file improvisation.

Static export vs a Node server — know which you're building

A surprising number of Next.js problems come from teams not knowing whether they're shipping a static site or a running server, and reaching for features the target can't support. Pick the deployment model early; it constrains everything downstream.

Boring wins

The most reliable Next.js apps I've built were aggressively boring: clear rendering choices, a thin data layer, conventions written down, no clever caching nobody understands. The framework gives you a lot of rope. Production is the discipline to not hang the team with it.