Next.js 15 App Router in Production: What We Learned After 20 Builds

After a year of running the App Router in production across SaaS dashboards, e-commerce storefronts and marketing sites, the verdict is clear: Server Components are the right default. Data-fetching co-located with the component, zero client JavaScript for static UI, and dramatically smaller bundle sizes.

The mental model shift is real, though. Teams used to "everything is a client component" need a few weeks to internalise the boundary. Once they do, productivity climbs — most pages need less code than the Pages Router equivalent.

Server Actions removed the boilerplate of writing route handlers for every form submission. For 80% of internal CRUD UIs, they are the cleanest pattern we have used.

The trap is using them as a general-purpose API. They are HTTP under the hood, but they hide that fact — making auth, rate-limiting and observability easy to forget. For anything called from a third-party client or a mobile app, write a real route handler.

PPR ships a static shell instantly and streams the dynamic parts in. A product page renders the header, hero and SEO content in under 200ms, while pricing and inventory stream in 400ms later. Users perceive it as instant.

On three e-commerce sites we measured LCP improvements of 35–60% compared to fully dynamic SSR — without losing personalisation.