The default that keeps earning its place
When DIGISUBS started, the web development conversation was a five-way argument: Gatsby, Next, Nuxt, Remix, or roll your own. Five years later most of that argument has resolved. Next.js is not the only good answer, but it is the one we reach for first on the overwhelming majority of new projects, and the reasons have changed since we started.
In the early days we picked Next.js mostly because of static export and good React integration. Today the reasons are different — and arguably stronger. The framework has matured into a serious platform for both marketing sites and production applications, with a coherent story for performance, SEO, and developer experience that no competitor has fully matched.
What Next.js actually solves
The honest answer is: a lot of the boring infrastructure decisions that used to take a week to argue about. Routing, server-rendering, code-splitting, image optimisation, font loading, edge deployment, basic analytics integration — all of this is opinionated and good-by-default in Next. We do not have to write a single config file to get a site that scores 100 on Lighthouse for performance, accessibility, and SEO. That is not a small thing. Five years ago it would have taken our team a sprint of tuning to reach the same place.
The App Router (which became default with Next 13 and stabilised through Next 14) was a real shift. Server components changed how we think about data flow — instead of every page hydrating a tree of client components, we now ship JavaScript only for the pieces that need interactivity. On a marketing site, the JS payload often drops by 60 to 80 percent compared to a traditional SPA architecture, and Time-to-Interactive collapses with it.
The tradeoffs we accept
Next is not free. There are tradeoffs we have learned to live with.
Vendor leverage. Next is open-source but its sponsor (Vercel) shapes the roadmap. Most of our deployments are on Vercel because the platform is genuinely the best Next host, but that is a coupling. We balance it by keeping our applications portable — no Vercel-specific APIs in app code — but we are honest that the easiest path runs through their infrastructure.
Build complexity. A modern Next.js project has more moving parts than a static site generator from 2018. ESM/CJS interop, server vs. client components, edge vs. node runtimes — these are real cognitive load. We onboard junior engineers to it carefully because the failure modes can be subtle.
Server cost at scale. SSR is more expensive than static, especially on high-traffic pages. We mitigate with aggressive ISR, RSC streaming, and edge caching, but for very high-traffic public pages a pure static generator can still be cheaper to operate.
When we don't reach for Next.js
There are projects where Next is the wrong tool, and we want to be honest about which ones:
Pure documentation sites. Astro is faster to build, faster to render, and easier to maintain for content-heavy sites with little interactivity. We have shipped several documentation sites on Astro in the last year and never regretted it.
Native-feeling mobile apps. If the experience needs to feel native on iOS and Android, we don't try to fake it with a PWA. Expo + React Native is our go-to for cross-platform native, and SwiftUI / Compose for single-platform.
Heavy real-time apps. For apps where 80% of the experience is real-time collaboration (think Figma, Linear), the Next.js architecture is fine for the marketing site but the actual product is usually built in a different stack with WebSocket-first state management.
Tiny one-page sites. A single landing page with no scaling story can ship as plain HTML faster than as a Next.js project. We will spin up a Next project anyway because consistency across our portfolio matters, but the cost-benefit is closer than people think.
What we ship by default
Every Next.js project we ship today comes with the same baseline:
- App Router with strict TypeScript everywhere.
- Tailwind CSS for styling, with a project-specific design tokens file.
- Sanity, Contentful, or markdown-in-repo for content (depending on team size).
- Vercel deployment with preview environments per PR.
- Cloudflare on top for DDoS protection and edge caching where the project warrants it.
- Sentry for error monitoring, PostHog or Plausible for analytics.
- Lighthouse CI in the pipeline so performance regressions break the build.
This stack has become our company's "boring default" — the thing we use unless there is a specific reason not to. Boring defaults are underrated. Every project that uses them inherits a year of bug fixes, performance work, and tooling decisions for free. The dramatic engineering decisions are best saved for the parts of the system where the product genuinely demands them.
The bigger lesson
The framework you choose matters less than the discipline with which you use it. We have seen messy Next.js codebases and elegant Remix codebases and both extremes in between. Frameworks set a floor on quality but not a ceiling. The team's habits — their willingness to write tests, refactor, and resist accidental complexity — determine the long-term health of the codebase far more than the framework choice ever will.
We pick Next.js because the floor it sets is high, the ceiling it allows is high enough, and the developer ergonomics are the best the React ecosystem has produced. That is not the same as "Next.js is the right answer to every question". It is the right default, which is a much more useful thing.