How I use Next.js at work

Next.js is my default for web products, and not because it is fashionable. It lets one TypeScript codebase cover what used to be three projects: the marketing site that has to rank, the app behind the login, and the thin API layer between them. This site is a small example - localized routes, generated metadata, a sitemap, Open Graph images, and an llms.txt route, all from the same App Router project.

I start server-first. Pages and layouts are Server Components by default: they fetch data close to the database, send HTML instead of a JavaScript bundle, and keep secrets on the server. “use client” goes only on the leaves that need state, effects, or browser APIs - a form, a dropdown, a map. When a tree starts with “use client” at the very top, a heavy bundle and a class of bugs usually follow.

Choosing a rendering mode is a product decision, not a technical one. Static generation for pages that change on deploy. ISR or tag-based revalidation for catalogs, listings, and blogs that change during the day - revalidateTag after a write, not a timer nobody understands. Dynamic rendering with Suspense streaming for dashboards and anything personal, so the shell appears instantly and slow data fills in. For every route I write down why it is static or dynamic; that one line saves a week of “why is the price stale?” later.

For mutations I use Server Actions for forms that belong to the page, and Route Handlers when something outside the app has to call in - webhooks from a payment provider or Telegram, a mobile client, a cron. Either way the input is validated with Zod on the server, auth is checked on the server, and the client never decides anything about money or permissions. In bigger products Next.js stays the frontend and BFF, while the core domain lives in a NestJS or Node.js service with its own database.

Performance and SEO are part of the definition of done. next/image with real sizes, next/font to kill layout shift, generateMetadata and structured data on every public page, dynamic imports for heavy widgets, and Core Web Vitals checked on a mid-range phone, not a MacBook. Deployment is either Vercel, when the team wants zero ops, or a standalone build in Docker on AWS or a VPS, when cost, data residency, or long-running jobs matter.

What I refuse: “use client” on the root layout, the same data fetched in five components with no thought about caching, business logic hidden in middleware, and a major-version upgrade on a Friday without reading the codemods. If you have a Next.js app that feels slow or fragile, send me the repo and the two slowest pages. I will reply with what I would move to the server, what I would cache, and what I would delete.