How do you organize a large Next.js App Router project (colocation, private folders, route groups)?

Q: How do you organize a large Next.js App Router project (colocation, private folders, route groups)?

**Target Audience:** Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. **Difficulty:** Medium > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:`. Every behaviour claim was checked against the Next.js 16.4.2 docs shipped with the package and, in the **Verified** section, against real output from a build, a running server or a real Chromium browser. ## 1. Why This Even Matters — A Story First Imagine a department store where the shop floor and the stock room are the same room. Customers wander into boxes of unpacked stock, and staff cannot find anything. A good store keeps one rule: **only the shop floor has customer doors**. Behind those doors you can store whatever you like, and you can put up signs ("Menswear", "Kitchen") that help staff without changing the street address. The Next.js App Router works the same way. The folders in `app/` define URLs, but a folder only

The problem

Question presented to candidate: "Our Next.js app has grown to 200 routes and four teams. Files are everywhere. How would you structure the app directory so it stays navigable, and which Next.js conventions help?"

What a strong answer should cover:

Only page and route files make a URL public, so components, tests and helpers can be colocated inside app/ safely.
Private folders (_components) opt a folder and everything under it out of routing; %5F creates a real URL segment that starts with an underscore.
Route groups ((marketing), (shop)) organize by section or team and attach different layouts without changing the URL.
Multiple root layouts via groups cause a full page load when navigating between them; two groups resolving to the same path fail the build.
A clear split between route code in app/ and shared domain code (lib/, features/, a server-only data layer), plus an import alias like @/.

Clarifying questions expected:

"Do sections need different root layouts (different html, fonts, providers)?" — that decides between one root layout and several.
"Are teams split by feature or by layer?" — it decides whether to group folders by feature or keep shared code outside app/.

Code / implementation expected: Yes — a folder tree using route groups and private folders, and the layouts that go with them.

nextjs
project-structure
app-router
architecture

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. Difficulty: Medium

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term:. Every behaviour claim was checked against the Next.js 16.4.2 docs shipped with the package and, in the Verified section, against real output from a build, a running server or a real Chromium browser.

1. Why This Even Matters — A Story First

Imagine a department store where the shop floor and the stock room are the same room. Customers wander into boxes of unpacked stock, and staff cannot find anything. A good store keeps one rule: only the shop floor has customer doors. Behind those doors you can store whatever you like, and you can put up signs ("Menswear", "Kitchen") that help staff without changing the street addre

The solution is hidden so you can try first

10 min read · 9 sections

Read the code

A feature-first layout for a large App Router project

src/
├── app/                          # routing only: URLs, layouts, loading and error UI
│   ├── layout.tsx                # one root layout (html, body, global providers)
│   ├── (marketing)/              # route group: not part of the URL
│   │   ├── layout.tsx            # marketing nav and footer
│   │   ├── page.tsx              # "/"
│   │   └── pricing/page.tsx      # "/pricing"
│   ├── (shop)/
│   │   ├── layout.tsx            # shop header with cart
│   │   ├── _components/          # private folder: never routable
│   │   │   └── CartSummary.tsx
│   │   ├── cart/page.tsx         # "/cart"
│   │   └── products/[id]/
│   │       ├── page.tsx          # "/products/:id"
│   │       ├── ProductGallery.tsx  # colocated, not routable (no page or route file name)
│   │       └── page.test.tsx       # colocated test
│   └── dashboard/
│       ├── _lib/queries.ts       # route-local server code
│       ├── layout.tsx
│       └── page.tsx              # "/dashboard"
├── features/                     # domain code shared by several routes
│   ├── billing/
│   │   ├── billing.server.ts     # import "server-only"
│   │   └── InvoiceTable.tsx
│   └── catalog/
├── components/ui/                # design system primitives
└── lib/                          # db client, auth helpers, env parsing

# tsconfig.json: "paths": { "@/*": ["./src/*"] }  so imports read "@/features/billing/..."

Route groups with their own layouts, plus a colocated private component

// app/(shop)/layout.tsx: applies to /cart and /products/*, not to /pricing
import { CartSummary } from "./_components/CartSummary";

export default function ShopLayout({ children }: { children: React.ReactNode }) {
  return (
    <div data-section="shop">
      <header>
        Shop <CartSummary count={3} />
      </header>
      {children}
    </div>
  );
}

// app/(shop)/_components/CartSummary.tsx: private folder, so even a page.tsx here is ignored
export function CartSummary({ count }: { count: number }) {
  return <span>{count} items in cart</span>;
}

// app/(marketing)/layout.tsx: a different layout for the same URL level
export default function MarketingLayout({ children }: { children: React.ReactNode }) {
  return (
    <div data-section="marketing">
      <nav>Marketing nav</nav>
      {children}
    </div>
  );
}

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.