Next.js's architecture is working. Its operating manual isn't keeping up.

A developer who says he has shipped production Next.js on every major release from 12 through 15 has published a split verdict on the framework: the core bets, React Server Components, Partial Prerendering and the App Router, are paying off in measurable ways, while the operational complexity has grown faster than the documentation explaining it ^[1][2]. If that reading holds, the risk in picking Next.js has moved. It is less likely to be architecturally wrong and more likely to be expensive to learn, staff and maintain.

The wins in his account are specific. On a marketing site backed by Sanity, the entire content-fetching layer, GROQ queries, image URL building and structured data construction, sits in server components with zero client JavaScript on those paths, and the homepage ships 38 kB of first-load JS with GSAP scroll animation still in place ^[3][4]. He has run Partial Prerendering in production on two sites since Q1: the shell prerenders to the CDN edge, session-dependent content streams in behind a Suspense boundary, and time to first byte on the static shell comes in under 40 ms on Vercel's edge network ^[5][6][7]. On a codebase of roughly 80 route segments with Tailwind v4 and some MDX, Turbopack took local cold start from about eight seconds to under two, a cut of at least 75 per cent ^[8][9]. He also reports no longer fighting the framework on SEO basics, with generateMetadata, next/image against Sanity's CDN and JSON-LD in a server component composing cleanly, in contrast to juggling Head in the Pages Router ^[10].

The costs are equally concrete, and they are onboarding costs. The four-layer cache model, request memoisation, Data Cache, Full Route Cache and Router Cache, produces production bugs he describes as difficult to reproduce ^[11]. His most frequent one: a Sanity webhook fires, revalidatePath runs, the route cache clears, but the client Router Cache serves stale data for the rest of its 30-second window, so editors see the update in Studio and the old version in browser preview ^[12]. The patch is scattering router.refresh() calls into client components, which he reads as the abstraction leaking ^[13]. The 'use cache' directive in Next.js 15 makes caching explicit rather than implicit, but adopting it means auditing every existing fetch call, which on a mature codebase takes days ^[14].

Then the recurring bill. Versions 13, 14 and 15 each required meaningful changes to routing, caching and component boundaries ^[15]. He tracks upgrade time per engagement: a minor bump on a Sanity plus Next.js plus Vercel site is usually an afternoon, a major bump touching App Router behaviour has consistently been two to four days including testing ^[16]. Across those three transitions that is six to twelve days per codebase, before any feature work ^[17]. He frames release velocity as a competitive feature for Vercel and a real cost for maintenance-phase projects ^[18].

On portability he is direct: PPR, after(), ISR with on-demand revalidation at scale and the Edge Runtime are designed and optimised for Vercel's infrastructure ^[19]. Self-hosting on Node or Docker keeps core routing working, but PPR depends on the edge runtime model Vercel runs natively, and after() is polyfilled differently depending on host ^[20].

These are one practitioner's self-reported numbers from client work, not independently reproduced benchmarks ^[1][16]. Worth watching whether the caching documentation catches up to the four-layer model, whether 'use cache' adoption reduces stale-preview bugs or just relocates them, and what a Next.js 16 upgrade costs against his two-to-four-day baseline.