When a new web product starts with a blank repo, we default to Next.js 15 on React 19. Not because it's the trendy choice, but because for the shape of product most of our clients are building — a marketing-facing site backed by a real application, or a full product with both public and authenticated surfaces — it removes more early friction than any alternative we've used.
That said, "default" is doing real work in that sentence. It's a starting point we override when a project's actual shape calls for something else, which we get into at the end.
Server components mean less JavaScript shipped to the browser
React Server Components let a component render on the server and send finished HTML (plus a small serialized payload) to the browser, instead of shipping the component's full JavaScript bundle for the client to execute. In practice, that means pages composed mostly of server components — which describes most marketing pages, content pages, and read-heavy dashboard views — ship dramatically less client-side JavaScript than an equivalent client-rendered app.
Less JavaScript means less to download, less to parse, and less to execute before a page feels interactive. For anything where first-load performance matters — and for most public-facing products, it does — that's a meaningful head start before any hand-tuning.
Easier SEO and metadata for marketing-facing pages
Server-rendered pages give search engines and social platforms a fully formed HTML document on first request, rather than an empty shell that fills in after JavaScript runs. Next.js's metadata API also makes per-page title, description, Open Graph and structured data straightforward to set — including dynamically, for pages generated from data like blog posts or product listings — without hand-rolling a separate rendering path just for SEO.
For a site like an agency's own marketing pages, or any product where organic search and link previews matter, that's a meaningful chunk of "SEO work" that's just handled by the framework's defaults rather than bolted on afterward.
The app router speeds up the first few weeks
The file-based app router — where a folder structure maps directly to routes, layouts and loading states — gets a project from an empty repo to a navigable, multi-page product faster than wiring up routing, layouts and data fetching by hand. Nested layouts mean shared UI (navigation, sidebars, providers) doesn't have to be re-derived per page. Built-in conventions for loading and error states mean those aren't an afterthought bolted on in week six.
This mostly pays off early. By the time a product is mature, the routing structure is what it is regardless of framework — but getting there faster means more of the project's timeline goes toward the actual product instead of scaffolding.
Client interactivity is still there when you need it
Defaulting to server components doesn't mean giving up rich interactivity. Any component can opt into being a client component — with full access to state, effects and browser APIs — for the parts of a product that genuinely need it: a drag-and-drop board, a live chart, a form with real-time validation, a chat interface. The framework's default just shifts the starting point so that interactivity is something you add deliberately where it earns its cost, rather than something every component pays for by default.
Deployment: edge-ready without extra setup
Next.js deploys cleanly to Vercel, Cloudflare, and standard Node hosting, with the option to run individual routes on edge runtimes for lower latency to global users. For a distributed team working with clients across time zones, being able to deploy globally without standing up custom infrastructure is a practical advantage, not just a checkbox.
Being honest about the tradeoffs
None of this makes Next.js the automatic right answer, and we don't treat it that way:
- React Server Components have a real learning curve. The mental model of what runs on the server versus the client, when data can be fetched where, and how server and client components compose — trips up teams used to a purely client-rendered React app. It's worth the investment for the right project, but it is an investment.
- Not every project needs server-side rendering. A purely internal tool behind auth, with no SEO surface and no first-load performance pressure, often does fine as a plain client-rendered single-page app — bringing in RSC complexity there is unnecessary.
- Content-heavy sites with little interactivity — documentation, a blog with no dynamic app behind it — are frequently better served by a static-first tool like Astro, which ships even less JavaScript by default for that specific shape of site.
- Some architectures are better served by a clean split — a dedicated backend API with a separate frontend — particularly when the API needs to serve multiple clients (web, mobile, third-party integrations) beyond a single website.
The point isn't that Next.js wins every comparison. It's that for the specific, common shape of "a real product with a public face and application logic behind it," it removes enough default friction — performance, SEO, initial routing and layout work — that we start there and change course only when a project gives us a concrete reason to.
More from the blog:
Building a new web product? Let's talk stack.
Tell us what you're building. We'll reply within one business day with honest feedback on the right architecture — not just the one we default to.