When a client comes to us with a new web project, the first technical question we face is: what framework? Six years ago that was a long conversation. Today, for most projects, we default to Next.js in the first five minutes.
This isn't religious loyalty. It's the result of shipping dozens of production systems and having strong opinions about what matters in a framework choice.
What We Actually Care About
Deployment flexibility without the vendor lock-in anxiety
Next.js can be self-hosted, deployed to Vercel, run on AWS Lambda, or packaged into a Docker container. That optionality matters. Early in a project's life, Vercel's ease is a genuine time-saver. As projects grow, the ability to move is important. We've ported several apps off Vercel when cost or compliance requirements changed — and it was never the disaster it could have been with a more opinionated platform.
Server Components change the economics of data fetching
React Server Components, shipped properly via Next.js, let us co-locate data fetching with the components that need it. This removes an enormous amount of wiring. No more prop drilling just to get server data into a component three levels deep. No waterfall of useEffect calls on mount. The component fetches what it needs, renders once on the server, and ships HTML to the browser.
The performance implications are real. We routinely achieve sub-200ms Time to First Byte on content-heavy pages that would have required significant caching infrastructure in a pure SPA.
The App Router is now production-ready
It took a version or two to stabilise, but the App Router is now what we recommend for all new projects. Nested layouts, parallel routes, and route interception cover 95% of the routing complexity we encounter in real applications. The remaining 5% requires creative solutions — but that's true of every framework.
When We Don't Use Next.js
There are legitimate cases where Next.js is the wrong tool:
Purely static sites with no dynamic content. If a marketing site has five pages that change quarterly, Astro or even plain HTML is the right choice. Next.js adds complexity that isn't justified.
Highly interactive, offline-first SPAs. If the entire application runs in the browser and never needs a server render — think complex diagramming tools or desktop-replacement web apps — the overhead of the server/client distinction creates more friction than value.
Mobile apps. Obviously. Though Next.js and React Native can share a lot of business logic and component-level code, which is a genuine win for teams building both.
The Framework Question Is Usually Not the Important Question
Here's the honest conclusion: for most web projects, the framework choice matters less than the architecture decisions you make within it, the quality of the team writing the code, and how well you understand the problem you're solving.
We default to Next.js because it gets us to the important questions faster. It removes known-good decisions from the table so we can focus on the unknown ones.
That's what a good default is for.