Project Structure

The project structure is similar to a classic Next.js project, with some changes that let us split the responsibility of components and hooks by domain – like in Bulletproof React:

app – builds paths, with groups for different layouts

components – simple, “static” components with no extra actions. Think of them as “what”: for example, a button that shows loading after you click and runs some function. Components are used by features, not the other way around.

content – used to store any kind of content, like mdx files for Fumadocs.

features – all features used in the app. Features are always a mix of actions and components that belong together. A component like store_product needs an action to get product info, so both are part of the store feature.

hooks – shared hooks used across the whole app. If you need a hook in more than one feature, put it here. Also, if a hook is broad and can work in different parts of the app, it goes here.

lib – reusable libraries, already set up for your app.

features – features are not static; they have a clear purpose and are used in a specific context.

public – all public media available to anyone, everywhere. Every file in public is open for everyone.

callbacks – we name callbacks with on before the event name to show it’s a callback.

services – includes all services used in the app. A service is anything used in many places, like an Axios instance to make API calls.

types – stores all declared types depending on the use case. For example, api.ts holds types for models used in API calls and data serialization.

utils – holds things that don’t fit into other parts of the project. If you’re not sure where something should go and it doesn’t match the project structure for features or deployment, put it in utils.

Feature structure

Inspired by the great idea from Bulletproof React, we build each feature as a complete unit with related components, hooks, and other functions:

api – handles API data fetching using Axios and useQuery.

hooks – feature-specific hooks that might call API hooks or work without APIs.

components – feature-specific components that use API and hooks from the same feature.

App structure

Layouts in Next.js can be tricky, especially when you need public, private, or custom layouts for different pages. That’s why we split the structure into two main groups: app and landings.

Next to those, you’ll find global files used by all layouts:

fonts – for different fonts used across layouts.

globals.css – CSS file with styles shared across all layouts.

robots.tsx – auto-generates a robots.txt file for SEO bots, based on your app setup.

sitemap.tsx – auto-generates a sitemap for SEO bots.

Folders with () brackets are groups. Groups are not part of the path. They just group content and let us apply different layouts to each group. Next.js works like a chain, passing children down. That’s why we need to carefully plan the app structure. We created 3 groups:

1. (private) – Uses AuthLoader to allow only logged-in users to access.
2. (public) – No extra wrapper; open for everyone.
3. (docs) – Uses Fumadocs RootProvider to display mdx files.

Docs structure

The built-in Fumadocs engine lets you create clean and good-looking documentation – just like the one you are reading now. Everything is ready to go, and you can use custom components in your documentation.