Three years ago we made a deliberate call: standardise our client stack around Next.js and React. Not because it was trendy, but because the cost of context-switching between frameworks was quietly killing our delivery speed.
The real cost of framework diversity
When you maintain projects across Vue, Nuxt, SvelteKit, and Next.js simultaneously, your engineers carry four mental models in their heads at once. Every context switch — even within the same day — costs roughly 20 minutes of re-orientation. Across a 10-person team, that is hours of productivity burned daily.
Standardising on Next.js meant our shared component libraries, our CI/CD templates, our observability patterns, and our deployment playbooks all converged on one target. A developer finishing one project could be productive on the next one within hours, not days.
What the App Router changed
The introduction of the App Router with React Server Components shifted the calculus significantly. Fetching data directly in server components — without waterfalls, without useEffect chains, without client-side loading skeletons for every route — produces a measurably better user experience and a cleaner codebase.
We have rebuilt three client dashboards this year using RSC patterns. In each case, initial page load improved by 30–50% and the codebase shrank by roughly a fifth. Less client JavaScript means less to parse, less to hydrate, and fewer things that can go wrong in the browser.
When we would not recommend it
Next.js is not the right tool for every job. If you are building a heavy real-time collaborative editor, a canvas-heavy design tool, or a game, you want full control over the rendering loop. If your team is deeply experienced in a different framework and your timeline does not allow for ramp-up, staying put is often the right call.
The framework wins when you need fast, SEO-optimised, data-driven pages delivered by a team that will not be around forever to maintain them. That describes the majority of what we build.