How I Structure Next.js Projects in 2026

After several production Next.js apps, I've settled on a folder structure that scales well. Here's exactly how I do it and why.

The Structure

Here's the folder layout I use for most projects:

/app                 — Next.js App Router pages & layouts
  /components        — Page-specific components (prefixed _)
  /(routes)          — Route segments
/components          — Shared/reusable components
  /ui                — Primitive UI components (Button, Input, etc.)
  /layout            — Layout components (Navbar, Footer)
/data                — Static data, mock data, constants
/libs                — Utility functions, helpers, config
/providers           — React context providers
/public              — Static assets
/langs               — i18n strings

Why This Works

Colocation. Page-specific components live next to the page that uses them (prefixed with _ to make them easy to spot). Shared components live in /components. You always know where to look.

Separation of concerns. Data is separate from UI. Utilities are separate from components. When you need to find something, you know which directory to check.

Scalability. This structure works for small sites and large apps. You add to existing directories rather than creating new organizational layers.

What I Avoid

Deep nesting. More than 3-4 levels deep becomes hard to navigate.
Mixing concerns. A component that also fetches data and contains business logic is harder to test and reuse.
Premature abstraction. I don't create a generic system until I see the same pattern appear three times.

The Bottom Line

There's no universally correct folder structure. The best structure is one your whole team understands and follows consistently. This one works for me — feel free to adapt it.