We use Next.js for most web app projects now. After building several client products with it, we have a pretty clear picture of when it works well — and when you'd be better off with something else.
Why We Default to Next.js
The main reason is flexibility. You can render pages on the server, pre-build them as static files, or update them incrementally — page by page, depending on what that page needs. That matters when you're building something with a mix of marketing pages, dashboards, and logged-in areas.
"You get control over how each page loads without making the developer experience painful. That's hard to find elsewhere."
What We Actually Do on Projects
- App Router vs Pages Router: We recommend the App Router for all new projects — it supports React Server Components by default, reducing client-side JavaScript.
- Data Fetching: Use server-side data fetching with React's cache API for deduplication and performance.
- State Management: Zustand or Jotai for client state; avoid Redux for new projects unless required by the team.
- Database Layer: Prisma ORM with PostgreSQL for type-safe database access.
A Typical Project Structure We Use
/api → API route handlers
/dashboard → Protected admin routes
/(auth) → Login, register, reset
/components → Shared UI components
/lib → DB client, helpers, utils
/hooks → Custom React hooks
/types → TypeScript type definitions
Real Numbers From Our Projects
On three client projects we shipped in 2025–2026, Next.js apps consistently scored 90+ on Lighthouse. Image optimization, automatic code splitting, and server-side rendering fixed most of the performance issues we'd struggled with on plain React SPAs.
Bottom Line
Next.js is our go-to for business web apps that need fast load times and good SEO. It's not right for everything — apps with heavy real-time features might still need a different setup — but for most of what our clients ask for, it's the best option we've found.