// overview
What "React and Next.js development" actually covers
Next.js gives you server components, streaming, and three different ways to render a page — but it doesn't decide which one your product needs. That decision, made route by route, is most of the actual engineering work behind a fast, maintainable app.
App Router architecture
Server and client components split deliberately, so only the interactive parts of a page ship JavaScript to the browser.
Rendering strategy per route
Static generation, ISR, or server rendering chosen by how often each page's content actually changes, not one default for the whole app.
Core Web Vitals performance
LCP, INP and CLS treated as build budgets from the first commit, measured with Lighthouse and real field data.
TypeScript end to end
Shared types across API routes, Server Actions and components, so a backend change surfaces as a type error, not a runtime one.
Data fetching & state
Server Actions for mutations, React Query for client-side caching, and a clear line between the two instead of both fighting over the same data.
Design system integration
Tailwind and a component library like shadcn/ui wired up with tokens that match your brand, not the library's defaults.
// rendering strategy
Picked per route, not per project
Marketing pages
Built once at deploy time. Fastest possible load, no server work per request.
Blog & product pages
Served static, revalidated in the background on a timer so content stays current without a full rebuild.
Authenticated dashboards
Rendered per request, so every user sees their own live data with no stale cache.
Personalization & A/B
Decisions made at the edge before the page renders, for the parts that need to differ per visitor.
// process
How the build runs
Architecture audit
Map every route to a rendering strategy and a server/client component split before any code gets written.
Foundations
Project scaffolding, TypeScript config, design tokens, and the data layer set up so every route built afterward follows the same pattern.
Route-by-route build
Pages and components built against the architecture plan, with each route's rendering strategy applied as it's written, not retrofitted.
Performance pass
Bundle size, Lighthouse scores, and Core Web Vitals checked against budget before anything ships.
Deploy & monitor
Shipped with error tracking and vitals monitoring in place, so regressions surface from real traffic, not guesswork.
// stack
Tools this is typically built with
// faq
Questions that come up early
Should each page use SSR, SSG, or ISR?
It depends on how often the content changes. Pages that are identical for every visitor are statically generated. Pages that change occasionally use ISR, revalidating on a timer. Pages that must reflect the current request, like a signed-in dashboard, render on the server per request.
Is App Router or Pages Router the right choice?
New projects use the App Router — that's where server components, streaming, and persistent layouts live. An existing Pages Router app gets migrated route by route rather than rewritten all at once.
Where should the app be hosted?
Vercel is the default recommendation for ISR, edge functions and preview deployments. Self-hosting on a Node server or container works too when the infrastructure needs to stay in your own environment, with any feature trade-offs flagged up front.
Can Core Web Vitals actually be guaranteed?
A specific number can't be promised in writing since real-user conditions vary, but the build targets LCP, INP and CLS budgets from day one and is measured against them, rather than patched after launch.
Can an existing CRA or Vite app move to Next.js?
Yes. Routing and data fetching change, but most components and business logic carry over. The usual path runs both apps side by side behind a proxy, migrating routes incrementally so the product stays shippable throughout.
Have a Next.js build to scope?
Send over what the app needs to do, and get back a route-by-route rendering plan before any code gets written.
Start a project