How to organize a Next.js project in a monorepo architecture? Advantages, tools, folder structure, and advice from my experience on high-volume applications.

When developing a Next.js application that will grow over time β with multiple modules, backends, shared components β a monorepo architecture quickly becomes a necessity. After several projects, I'm sharing here my best practices for structuring a Next.js project in a clean, maintainable, and scalable monorepo.
A well-structured monorepo also allows multiple people to work without overwriting other modules.
projectReferencesmy-app/
βββ apps/
β βββ web/ β main Next.js app
β βββ admin/ β admin interface
βββ packages/
β βββ ui/ β shared components (design system)
β βββ config/ β Tailwind, ESLint config, etc.
β βββ db/ β ORM, Drizzle schemas, DB helpers
βββ .gitignore
βββ package.json
βββ turbo.json
βββ tsconfig.json
Each sub-project can have its own dependencies while accessing common packages via workspaces.
The packages/ui folder contains components like <Button />, <Card />, <Layout />, all written in TypeScript and styled with Tailwind.
// packages/ui/button.tsx
export function Button({ children }) {
return (
<button className="rounded-xl px-4 py-2 bg-orange-500 text-white">
{children}
</button>
);
}
Then, you import it from apps/web:
import { Button } from "@ui/button";
In packages/types, I place all my shared types between frontend, backend, and API. This allows strict typing, especially for data retrieved with Drizzle ORM.
For tests, each app can embed its own Jest/Vitest, or we can share helpers in packages/test-utils.
I support startups and ambitious web projects in their technical structuring, whether in creation or redesign.
π Discover my technical SEO services
π Contact me directly
π Schedule a 30-minute call
Β© 2026 MKWeb. All rights reserved.