Next.js Review (2026): Honest Assessment from BearPlex Engineers
Next.js is our default framework for anything with a public web surface, and the review you are reading is served by it: bearplex.com is a Next.js 16 App Router build with 440+ indexable routes, ISR against a live ATS, and an edge-rendered OG image service. The App Router's server-components model is genuinely the right architecture for content-heavy and programmatic sites, and it is also where teams hurt themselves: the server/client boundary reshapes bundles, and caching defaults have changed across major versions, so upgrades are behavioral work, not version bumps. The honest caveat is that not everything needs it; we still ship plain React SPAs when there is no SEO surface to win. The receipts and the full playbook live on our Next.js development service page.
Based on
6+ production projects
Next.js is our default framework for anything with a public web surface, and the review you are reading is served by it: bearplex.com is a Next.js 16 App Router build with 440+ indexable routes, ISR against a live ATS, and an edge-rendered OG image service. The App Router's server-components model is genuinely the right architecture for content-heavy and programmatic sites, and it is also where teams hurt themselves: the server/client boundary reshapes bundles, and caching defaults have changed across major versions, so upgrades are behavioral work, not version bumps. The honest caveat is that not everything needs it; we still ship plain React SPAs when there is no SEO surface to win. The receipts and the full playbook live on our Next.js development service page.
What is Next.js?
Next.js is Vercel's open-source React framework for full-stack web applications. The App Router (default since version 13) is built on React Server Components: components render on the server by default and ship no JavaScript to the browser unless explicitly marked as client components, which turns bundle size into an architectural property rather than an accident. Around that core sit file-based routing with nested layouts, streaming, static generation and Incremental Static Regeneration (ISR), per-route dynamic rendering, built-in image and font optimization, metadata and sitemap APIs, route handlers for APIs, middleware, and an edge runtime. It deploys with zero configuration on Vercel and self-hosts on any Node server or container via standalone output. For SEO-driven, content-heavy, and programmatic sites, it is the strongest option in the React ecosystem, which is exactly the workload this site uses it for.
| License | MIT (open source); Vercel is the commercial platform around it |
| Model | React Server Components by default; client components opt in via 'use client' |
| Rendering | Static, ISR, dynamic, and edge, chosen per route |
| Routing | File-based App Router with nested layouts, streaming, and generateStaticParams |
| Caching | Semantics changed across majors: 13/14 cached fetch by default, 15 flipped to uncached (verify on upgrade) |
| Best for | SEO-driven products, programmatic content at scale, e-commerce, content-heavy platforms |
| Worst for | Login-walled internal tools, native mobile, long-lived stateful servers |
| Hosting | Zero-config on Vercel; self-hosts via standalone output with real work (cache handler, image pipeline, CDN) |
| Active alternatives | React Router (Remix), Astro, Vite + React SPA, SvelteKit |
Hands-on findings from 6+ production projects
The system we know best is the one serving this page: bearplex.com is a Next.js 16 App Router build with 440+ indexable routes, most of them programmatic pages generated from typed data files via generateStaticParams, each carrying its own metadata, JSON-LD, and an OG image rendered by an edge-runtime route. The careers section regenerates through ISR every five minutes against a live ATS, so job postings go live between deploys without a rebuild. Beyond this site, our published Next.js case studies include Vertex360 (Next.js and TypeScript at the core of a 73K+ line NDIS platform with 32 modules, processing $1.2M+ in monthly claims), Yaay365 (a six-app ecosystem with its member website on Next.js 13 and marketing site on Next.js 14), and Optinizers (a retrieval interface on Next.js with the Vercel AI SDK), plus a delivered luxury designer-collections e-commerce build. The patterns that emerged: (1) The server/client boundary is the architecture. Server components by default keep bundles small; one careless 'use client' high in the tree drags a subtree into the browser bundle, so we review boundary placement like an API contract. (2) Caching must be explicit. The framework's defaults changed between majors 13 and 15, so every route in our builds carries a written caching policy, and version upgrades get route-by-route verification against it. (3) ISR is excellent when staleness is a product decision with a number attached, and wrong for anything per-user. (4) Programmatic SEO is the killer workload: typed data in, hundreds of consistent indexable routes out, with a sitemap that is code and cannot drift. (5) We deploy production builds to Vercel daily, and it is the path of least resistance; self-hosting works but you inherit the ISR cache handler, image optimization, and CDN pieces yourself. Full practice details at bearplex.com/services/nextjs-development.
Pros
- Server components by default make small bundles the starting point, not an optimization project
- The strongest programmatic SEO stack in the React ecosystem: generateStaticParams, metadata API, sitemaps as code
- ISR gives static-page performance with a freshness deadline (this site's careers pages run a five-minute window)
- Per-route rendering strategy: static, ISR, dynamic, and edge can coexist in one app
- Built-in image and font optimization remove two of the biggest Core Web Vitals footguns
- Streaming and nested layouts keep large pages responsive without client-side data waterfalls
- MIT-licensed and self-hostable via standalone output, so Vercel is a convenience, not a requirement
- Enormous ecosystem and hiring pool; it is the default React framework in practice
Cons
- Caching semantics changed across major versions; upgrades silently alter freshness unless verified route by route
- The server/client boundary is easy to get wrong, and the failure mode (bloated bundles, leaked server code) is quiet
- Complexity is real: for a login-walled SPA with no SEO surface, a Vite SPA is simpler to build and operate
- Self-hosting is documented but not free: multi-instance ISR needs a shared cache handler, images need their pipeline
- The framework evolves fast; patterns from an 18-month-old tutorial may already be the wrong ones
- Long-lived stateful workloads (websocket sessions, multiplayer state) fight its serverless-first grain
- Build times on large programmatic sites need active management as the route count grows
Next.js compared to alternatives
| Alternative | Score | Best for | Worst for |
|---|---|---|---|
| React Router (Remix) | 4/5 | Teams that want a leaner, web-standards-first React framework | Programmatic static generation at large route counts and ISR-style freshness |
| Astro | 4/5 | Content sites that want near-zero JavaScript by default | Deeply interactive application surfaces beyond islands |
| Vite + React SPA | 3.5/5 | Internal tools and dashboards behind a login, with no SEO surface | Anything that needs server rendering, crawlable HTML, or per-route metadata |
| SvelteKit | 3.5/5 | Teams happy to leave React for a smaller-runtime framework | Organisations standardised on the React ecosystem and hiring pool |
Pricing analysis
The framework is MIT-licensed and free; the costs are hosting and engineering. On Vercel, hobby projects run free and production teams pay per seat plus usage (bandwidth, image optimization, function execution), which for a typical mid-market marketing-plus-product site is modest next to the engineering it replaces; heavy image or traffic workloads should be modelled before launch rather than discovered on an invoice. Self-hosting on a VPS or container platform trades that bill for your own ops time: the standalone server, a CDN in front, an image pipeline, and a shared ISR cache if you scale horizontally. The line item teams actually underestimate is neither of those; it is upgrade engineering. Major versions have changed caching behavior, so budget real verification time per upgrade instead of treating it as a dependency bump. We deploy production builds to Vercel daily and recommend it as the default; the exit to self-hosting is engineering work we have planned, not a trap.
When to use
- SEO-driven products where public pages, metadata, and crawlable HTML decide outcomes
- Programmatic content at scale: hundreds of indexable routes generated from typed data
- E-commerce catalogues that need static shells, fresh inventory, and personal carts in one app
- Content-heavy platforms where ISR's freshness-with-a-deadline model fits the editorial reality
- Teams standardised on React that want rendering strategy as a per-route decision
When NOT to use
- Internal tools behind a login: a Vite SPA is simpler (we ship plain React SPAs when they fit; SimpliRFP on this site is one)
- Native-feel mobile products: that is React Native's job, not a web framework's
- Mostly static brochure sites edited daily by non-technical teams: CMS-first setups often serve better
- Server-rendered CRUD with a team fluent in Rails, Laravel, or Django and new to React
- Products whose core is a long-lived stateful server: build that as a dedicated service
Next.js: questions answered
No. It self-hosts on any Node server or container via standalone output. The tradeoff is that ISR caching across instances, image optimization, and CDN configuration become your work instead of the platform's. We deploy production builds to Vercel daily and treat self-hosting as a planned engineering decision.
Because caching defaults changed across majors: versions 13 and 14 cached fetch calls by default, version 15 flipped fetch and GET route handlers to uncached and reworked the client router cache. Code relying on implicit behavior changes meaning on upgrade. The fix is an explicit caching policy per route, verified after every major bump.
It is the best tool we have used for it. This site generates most of its 440+ indexable routes from typed data files with generateStaticParams, each with its own metadata, JSON-LD, and edge-rendered OG image, and ISR keeps them fresh without full rebuilds.
When nothing needs to be crawled: internal tools, dashboards, anything behind a login. A Vite SPA is simpler to build and operate there. We ship plain React when it fits; SimpliRFP, published on this site, is a React SPA. Next.js earns its complexity when public pages and search visibility are part of the product.
Server components stay the default, client components stay small and leaf-level, heavy interactivity sits behind dynamic imports, and per-route bundle budgets are enforced in CI. Most Next.js performance problems we audit are bundle problems: dependencies that drifted into client components one pull request at a time.
No, and it should never be asked to. ISR serves the same regenerated page to everyone, so anything per-user must render dynamically. ISR shines when staleness is acceptable with a number attached: this site's careers pages run a five-minute window against a live ATS because five minutes is fine for a job posting.
Yes: an audit of bundle composition, server/client boundaries, actual per-route caching behavior, Core Web Vitals field data, and the upgrade path, then a fixed-scope plan. Details at bearplex.com/services/nextjs-development.
Related reviews
Related services
Featured case studies
Research basis
- Next.js caching documentation · The official model for fetch caching, the router cache, and revalidation; the layer whose defaults changed across major versions.
- Next.js self-hosting documentation · Standalone output, custom cache handlers for multi-instance ISR, and the image optimization pieces self-hosters own.
- BearPlex Next.js development service · Our full Next.js practice: App Router builds, migrations, Core Web Vitals engineering, programmatic SEO, and the receipts behind this review.
Last researched: 2026-07-03
Disclosure: BearPlex is not affiliated with Vercel Inc. beyond deploying production builds on its platform as a paying customer. bearplex.com itself runs on Next.js, and our published case studies include Next.js client platforms. We do not receive any compensation, referral fees, or partnership benefits from Vercel Inc. Reviewed by Hamad Pervaiz, Founder & CEO, BearPlex.
Need help implementing Next.js at scale?
BearPlex builds production AI systems with Next.js and its alternatives. Outcome-based pricing.