Project organization in Next.js 15. Well, the first thing to mention here is that there's no right or wrong way to do this. I've set up projects in so many different ways, it ultimately depends on preferences of the development teams and there are lots of different ways to make it work. Ultimately the most important thing is making sure that however you decide to organize your project, to keep it consistent and make it consistent across your team.
When it comes to stuff like this, and this stuff also maybe includes different code formatting strategies and stuff like that, if you can automate any of this stuff it's generally a good idea. Whether it's true pre-commit hooks, github actions or anything alike, some of that stuff can really be helpful but I won't cover how to set this up in this post.
In this post I'll give you my loosely preferred method for organizing a Next.js 15 codebase, but I want to cover 3 methods that I've seen work for a lot of different development teams, and are covered in some of the Next.js documentation as well.
Managing your files in the root directory of your project
One way of doing things is storing everything inside the root directory of your project, outside of your app folder. You would create a structure that looks a bit like this.
├── .next
├── actions
├── app
│ ├── fonts
│ │ ├── GeistMonoVF.woff
│ │ ├── GeistVF.woff
│ ├── favicon.ico
│ ├── globals.css
│ ├── layout.tsx
│ ├── page.jsx
├── components
├── hooks
├── lib
├── node_modules
├── .gitignore
├── jsconfig.json
├── package-lock.json
├── package.json
├── postcss.config.mjs
├── README.md
└── tailwind.config.jsOrganizing your files in the app directory
Another approach that is common for Next.js projects is to place your folder structure inside the app folder.
├── .next
├── app
│ ├── actions
│ ├── components
│ ├── fonts
│ │ ├── GeistMonoVF.woff
│ │ ├── GeistVF.woff
│ ├── hooks
│ ├── lib
│ ├── favicon.ico
│ ├── globals.css
│ ├── layout.tsx
│ ├── page.jsx
├── node_modules
├── .gitignore
├── jsconfig.json
├── package-lock.json
├── package.json
├── postcss.config.mjs
├── README.md
└── tailwind.config.jsAs you can see we've now moved our actions, hooks, components and lib folder into the app directory. If you're newer to Next.js you might wonder if this makes your folders accessible to users of your application, but as long as you don't place a page.* file inside these folders, users won't be able to navigate to /components or any of the other folders, so this is perfectly safe to do.
Page specific components
Another way of organizing your Next.js project, and this is maybe a way to co-locate things a little bit more, is to split project files by feature or route. So say you have a /settings route with a page.tsx file inside of this. If you have components that are specific to your settings page, you could create a components folder right inside your settings page folder. This will make it clear that these components only get used for your settings page. However, you might still have a higher level components folder in place, which is where you place components that you're going to be using throughout your entire app.
├── .next
├── app
│ ├── actions
│ ├── components
│ ├── fonts
│ │ ├── GeistMonoVF.woff
│ │ ├── GeistVF.woff
│ ├── hooks
│ ├── lib
│ ├── settings
│ │ ├── components
│ │ ├── page.tsx
│ ├── favicon.ico
│ ├── globals.css
│ ├── layout.tsx
│ ├── page.jsx
├── node_modules
├── .gitignore
├── jsconfig.json
├── package-lock.json
├── package.json
├── postcss.config.mjs
├── README.md
└── tailwind.config.jsLarge scale project organization
As I've worked in more and more large scale projects with sometimes hundreds of different components, it just (for me anways) becomes a little bit too much to have one top level components folder, whether it's in or outside of your app directory folder. From my experience this becomes a little bit too much and it makes it difficult to navigate.
When your project starts getting bigger and you end up having hundreds of components, I personally find that having one top level components folder can be a little bit difficult to navigate.
What I have typically done for large scale projects, is split things by feature or route a little bit more. When there are components that we share across the entire application, so perhaps a generic button component that we use across our entire app, we place it inside app/components. But if we have specific components for a blog or settings, we would create a specific components folder there. That organization tends to be a little bit easier, especially in a large scale project.
If you're just creating a smaller project or perhaps a demo project for your portfolio or you're just coding out something for fun, I think any of the above approaches is fine. What I do recommend however is that you get consistency in how you organize your files, so pick one and stick to it.
My preference: splitting by route/feature
Since most of my work is now on larger scale projects, I tend to always split things by route or feature. At first it can take a little bit to get used to, if you're not used to it already, to have several different component folders inside your application, but you can always slightly rename them. An example of this would be: /app/blog/_components where you use the underscore to make it clearer these are folder specific components.
Once you get used to it, it makes quite a bit of sense and you'll find that your projects become much easier to navigate. More importantly however is that as long as you stick to it, and your team adheres to it. If you find that you have a route specific component, but you now need to use it across a differnt route as well, push it into your global components folder.
To wrap things up, as long as you have consistency across your team and different projects, you can make any of the above approaches work.
What is your favorite approach when it comes to organizing your Next.js projects? Let me know on LinkedIn or Threads and let's connect and exchange ideas!
Need a more robust structure for your Next.js projects?
If your team is grappling with an existing, large Next.js codebase, or you're planning a new project and want to ensure it's built with optimal scalability and maintainability from day one, I can help. As a Fractional CTO and technical advisor, my expertise lies in transforming complex codebases into clear, high-performing assets. Let's schedule a brief chat to discuss your specific challenges and how we can bring sustainable structure to your development efforts.
Let's schedule a chat