Next.js in Production: What We Wish We Knew Before Our First Client Launch

We build most client sites and apps in Next.js, and we still stand by it. But there's a real gap between "I followed the getting-started guide and it works on my laptop" and "this is live, a client's revenue depends on it, and Googlebot is crawling it right now." Here's what closed that gap for us, learned the expensive way.

1. Caching will surprise you before it helps you

The App Router's caching model is powerful once you understand it and confusing right up until that point. We've had a client swear their content update "didn't work," only to find the fetched data was cached exactly as configured — correctly, just not how they expected. Decide your caching strategy per data type before you write the fetch call, not after a client reports stale content.

2. Image optimization has a real bill attached

Next's image optimization is genuinely good, but on some hosting setups every unique image size counts against a transformation quota. A product catalog with a few thousand images, each rendered at three breakpoints, adds up faster than teams expect. We now plan image sizes deliberately instead of leaning on runtime transformation to do all the work — the same discipline that shows up in fixing a slow website without a rebuild.

3. Metadata and SEO are easy to get half-right

The Metadata API makes it trivial to add a title and description. It does not stop you from forgetting a canonical URL, shipping mismatched Open Graph image dimensions, or leaving a whole route with no metadata at all because it was added after the page went live. We run a checklist against every route before launch now, because "the API is easy" and "the site is actually well-optimized" turned out to be two different things.

4. Client components creep in faster than you'd think

It's tempting to slap "use client" on a component the moment you need one piece of interactivity, and then watch that directive drag half your component tree along with it into the client bundle. The fix isn't dogma about avoiding client components — it's pushing them as far down the tree as possible.

5. Your staging environment lies to you if it's too different from production

Edge runtime quirks, environment variable mismatches, and caching behavior can all differ between a local dev server, a preview deployment, and production. We've shipped bugs that only appeared once real traffic hit a production edge network. The fix is boring but effective: make staging match production configuration as closely as possible.

A framework doesn't ship your product for you. It just decides which mistakes are easy to make and which ones are easy to avoid.

None of this is a knock on Next.js — it's still our default choice, for reasons we get into in how we choose a tech stack without chasing hype. It's just that the honest version of "we use Next.js" includes a few hundred small decisions that don't show up in a tutorial, and we'd rather a client hear that from us upfront than discover it after launch.