Hey there! I've been working with Next.js for the past few years, and one thing I keep seeing is how confused developers get when setting up their project folders.
It's not their fault - there are so many ways to do it, and the docs sometimes feel a bit overwhelming.
The Problems We Face
When I first started with Next.js, I made a mess. My files were everywhere, components were hard to find, and other developers in my team kept asking "Where should I put this file?" Sound familiar?
Here are the main issues I've seen teams struggle with:
1. Files get scattered all over the place
2. No clear rules about where to put new components
3. Too many folders that no one understands
4. Mixing business logic with UI components
5. Confusion about where to put API calls
6. Utility functions spread across different folders
7. No standard way to handle types
8. State management files without proper organization
9. Hard to find and fix things when they break
10. New team members take forever to understand the structure
The Solution: A Clear, Logical Structure
After lots of trial and error, here's a folder structure that has worked really well for me and my teams. It's not perfect (nothing is), but it makes sense and helps new developers find their way around.
├── src/
│ ├── app/
│ │ ├── (auth)/
│ │ │ ├── login/
│ │ │ └── register/
│ │ ├── (dashboard)/
│ │ │ ├── settings/
│ │ │ └── profile/
│ │ ├── api/
│ │ │ └── route.ts
│ │ └── layout.tsx
│ ├── components/
│ │ ├── ui/
│ │ │ ├── button/
│ │ │ └── card/
│ │ └── shared/
│ │ ├── header/
│ │ └── footer/
│ ├── hooks/
│ │ ├── use-auth.ts
│ │ └── use-form.ts
│ ├── lib/
│ │ ├── utils.ts
│ │ └── constants.ts
│ ├── types/
│ │ └── index.ts
│ └── services/
│ ├── api.ts
│ └── auth.ts
├── public/
│ ├── images/
│ └── fonts/
├── tests/
│ └── components/
└── package.json
Let's Break It Down
The src Folder
We keep everything in src because it makes imports cleaner and separates our code from config files.
App Directory
The app folder is where Next.js routing magic happens. I use parentheses () for grouping related routes. For example, (auth) holds all auth-related pages.
Components Organization
- ui: Small, reusable pieces like buttons and cards
- shared: Bigger pieces used across many pages like headers and footers
Each component gets its own folder with its styles and tests.
Other Key Folders
- hooks: Custom React hooks we use a lot
- lib: Helper functions and constants
- types: TypeScript types we use across the app
- services: API calls and external service connections
Why This Works
1. Everything has a home - new files have clear places to go
2. Easy to find things - logical grouping helps developers navigate
3. Scales well - works for both small and large projects
4. Testing is straightforward - structure matches the code
5. New developers get it quickly - folders names make sense
This structure isn't set in stone. Your project might need something different. Maybe you don't need some folders, or maybe you need extra ones. That's fine! The key is having a structure that:
- Makes sense to your team
- Helps you work faster
- Keeps things organized as the project grows
- Doesn't get in your way
Tips for Using This Structure
1. Keep components small and focused
2. Use index.ts files to clean up imports
3. Group related features in route groups
4. Keep shared logic in hooks and services
5. Don't nest folders too deeply
The best folder structure is one that helps you and your team work better. Start with this setup, see how it feels, and adjust it based on your needs. The goal is to spend less time thinking about where files should go and more time building cool stuff.
Remember: It's okay to change things if they're not working. Good structure should help you, not slow you down.