When Next.js is the right framework
Next.js is a strong choice for marketing sites, content platforms, ecommerce storefronts and SaaS products where some pages must be public and indexable while others sit behind a login. It gives one codebase for both, with server rendering for search engines and rich client interactivity where needed.
It is less suited to pure internal tools with no public pages, where a lighter Vite setup is simpler, or to teams that want a backend-agnostic static site with very little JavaScript. For complex backend domains we keep Next.js as the web layer and run business logic in separate services.
| Strategy | How it works | Typical use |
|---|---|---|
| Static generation | HTML built ahead of time and served from a CDN | Marketing pages, documentation, blog posts |
| Incremental regeneration (ISR) | Static pages rebuilt after a time window or on-demand tag revalidation | Product catalogs, listings, CMS content |
| Dynamic server rendering | HTML rendered per request with fresh data | Personalized dashboards, account pages |
| Streaming with Suspense | Page shell sent first, slower sections stream in | Pages mixing fast and slow data sources |
App Router architecture
We build new projects on the App Router. Layouts persist between navigations, loading and error files give each route segment its own fallback, and route groups organize marketing, app and admin areas without affecting URLs.
- Server Components by default, with client components only where interactivity is needed, kept small and close to the leaves of the tree.
- Server Actions for mutations such as form submissions, validated with Zod and protected with authorization checks inside the action.
- Route handlers for webhooks, public APIs and endpoints consumed by mobile apps.
- A data access layer that centralizes queries and permission checks, so no component talks to the database directly.
Caching, revalidation and data freshness
Caching is where most Next.js projects go wrong. Newer Next.js releases moved toward explicit, opt-in caching, and we decide for each data source whether it should be cached, for how long, and what event invalidates it. Content from a CMS typically uses tag-based revalidation triggered by a webhook, so editors see changes within seconds without rebuilding the site.
User-specific data is never cached across users. We document the caching rules per route in the repository, and test them, because a stale price or another user's data on the wrong page is a far worse bug than a slow response.
SEO and Core Web Vitals
- Per-route metadata generated from content, including titles, descriptions, Open Graph images and canonical URLs.
- Programmatic sitemaps and robots rules, plus JSON-LD structured data for articles, products, FAQs and breadcrumbs.
- next/image for responsive, lazy-loaded images in modern formats, and next/font to avoid layout shift from web fonts.
- Third-party scripts loaded with the Script component and deferred strategies to protect Interaction to Next Paint.
For storefronts, these practices directly affect organic traffic and conversion; our ecommerce app development work applies them to catalog, search and checkout pages.
Testing, deployment and operations
We test Server Components and data functions with Vitest, client components with React Testing Library, and full journeys with Playwright against preview deployments created for every pull request. Lighthouse checks and bundle size budgets run in CI so performance regressions are caught before merge.
Deployment targets include Vercel, Docker containers on AWS, Google Cloud or Azure, and adapter-based AWS setups. Each platform handles ISR, image optimization and edge functions slightly differently, so we confirm behavior on the target platform early rather than at launch.
Authentication and security in Next.js
Server Actions and route handlers are public HTTP endpoints, even when no button in the UI calls them. We validate input and check authorization inside every action and handler, not only in middleware or layout components, because request interception alone is not a reliable security boundary.
- Session handling through a maintained auth library or identity provider, with secure, HTTP-only cookies.
- Strict separation of server-only modules so secrets and database clients can never be bundled into client code.
- Only intentionally public values exposed through public environment variables.
- Content Security Policy, rate limiting on auth and form endpoints, and dependency updates applied promptly when framework security advisories are published.
Migrating to Next.js
Teams often come to Next.js from a client-rendered React SPA, a WordPress site or an older Pages Router app. We migrate route by route where possible, keep URLs stable with redirects for anything that changes, and compare search traffic and Core Web Vitals before and after each phase, so SEO gains are measured rather than assumed.
How Next.js fits our stack
Next.js is our default framework when a React web interface needs public, indexable pages. It pairs with a Node.js API layer when business logic is substantial, or with a managed database and auth provider for smaller products.
Many of our SaaS products use Next.js for the marketing site, onboarding and app shell in one codebase. Startups planning a first version can review our MVP development approach and the MVP development cost guide, where typical first releases range from $30k to $90k depending on scope.