Six months with Next.js App Router: what we'd do differently

We moved several production apps to the Next.js App Router over six months. It is a genuine step forward — and it will also happily let you build something slow and confusing if you bring your old mental model with you.

Server components change where data lives

The biggest unlearning: data fetching belongs on the server, close to the component that needs it, not hoisted into a single top-level loader. Once that clicked, our components got smaller and our client bundles got dramatically lighter.

Caching is the footgun

The App Router caches aggressively by default across four different layers. Most of our early bugs were really caching bugs — stale data that looked like logic errors. Learn the cache model early and be explicit about revalidation.

Keep client components at the leaves

Interactivity should live at the edges of the tree. Pushing "use client" as far down as possible keeps the server-rendered core fast and the interactive islands small.

If your whole page is a client component, you are using a server framework to ship a single-page app.

Used with its grain, the App Router produces fast, SEO-friendly apps with very little client JavaScript. Used against it, you get the worst of both worlds.