How We Structure Our Next.js Projects (Simple and Boring)

Every time I see a "project structure" article it is always some over-engineered setup with 15 folders and custom abstractions. That works for big teams but for a small studio like ours, we keep it simple.

Here is how we organize our Next.js projects at Impeccify. Nothing fancy, just practical.

The folder structure

src/ app/ - Pages and routes components/ - Reusable UI components constants/ - Static data and configuration lib/ - Utility functions hooks/ - Custom React hooks styles/ - Global CSS (minimal with Tailwind) public/ - Static files

That is it. No domain folders, no feature folders, no barrel files. Just the basics.

Why this works for us

The app folder is flat

Every page gets its own folder inside app. We do not nest routes unless the URL structure actually requires it.
src/app/ page.jsx - Homepage tools/page.jsx - Tools hub blog/page.jsx - Blog hub px-to-rem-converter/ page.jsx layout.js chipotle-nutrition-calculator/ page.jsx layout.js

Each tool or page has its own folder with a page.jsx and layout.js. The layout.js handles SEO metadata and structured data. The page.jsx has the actual content.

Components are flat too

src/components/ Navbar.jsx Footer.jsx ChipotleCalculator.jsx PxToRemConverter.jsx FAQAccordion.jsx

No nesting. No index files. Every component is one file with a clear name. When you need to find something, you just search by name.

Constants hold all the data

This is probably the most unusual part of our setup. We put all static data in the constants folder.
src/constants/ chipotleNutritionData.js starbucksNutritionData.js dotsCalculatorData.js

Each data file has the formulas, presets, default values, and reference data for its calculator. This keeps the component files clean. The component handles UI and interaction. The constants file handles data and logic.

Lib is for shared utilities

src/lib/ utils.js paddle.js

Utility functions, API helpers, and third party integrations. We keep this small. If a function is only used in one component, it stays in that component.

What we skip

• TypeScript (for now, on small projects it adds time without much benefit for us)
• Testing framework (we test manually and in the browser)
• Storybook (we do not have enough components to justify it)
• Monorepo tools (we deploy one site at a time)
• State management libraries (React state and context is enough)

The point

You do not need a complex setup to build real products. We have shipped dozens of tools and service pages with this simple structure. It works because everyone (which is just me most of the time) knows exactly where everything goes.

Pick a structure that matches your team size. For solo developers and small teams, flat and simple beats nested and organized every time.