A Turborepo + Next.js 16 starter for internal tools and small dashboards: a public app and an admin dashboard on a set of shared packages.
An opinionated monorepo template you copy to start a new internal-tools project. It ships:
- Two apps — a public read surface (
@repo/web) and an admin dashboard (@repo/admin) — sharing data via@repo/dband identity via@repo/auth. - A generic example domain — an
Itemresource (status, owner, soft-delete) that demonstrates the full CRUD path so you can swap in your own model. - Batteries included — typed env, Better Auth (single admin role), Prisma + Postgres, a shadcn design system on tokens, Vitest + Playwright, lint/format/ commit hooks, structured logging, and optional Sentry + object storage.
The display name is set per project via NEXT_PUBLIC_APP_NAME (default
"Internal Tools"). Maps / PostGIS live on a separate feat/geo branch.
| # | Document | Purpose |
|---|---|---|
| 00 | Starter guide | Starting a new project: rename, env, first migration, pulling in feat/geo |
| 01 | Architecture | The big picture — monorepo layout, package boundaries, request flow |
| 02 | Getting started | First-time setup: install, env, DB bootstrap, running both apps |
| 03 | Database | Prisma schema, adapter, migrations, seeding, typed queries |
| 04 | Authentication | Better Auth config, roles, protecting routes, sessions |
| 06 | Design system | Tokens, typography, status tones, anti-patterns |
| 07 | API reference | HTTP endpoints + the Server Action surface |
| 08 | Deployment | Env per environment, build pipeline, hosting recommendations |
| 09 | Development workflow | Day-to-day: tests, migrations, adding tables/routes/components |
- Starting a new project? → Starter guide
- Want to run it locally? → Getting started
- Changing the schema? → Database — migrations
- Adding a new admin-protected route? → Authentication — protecting routes
- Building a new shadcn component? → Design system — adding components
- Want to deploy? → Deployment
Design decisions favor clarity over cleverness. A few load-bearing rules:
- No
any— write explicit shapes; type$queryRawrows with a generic. - No hard-coded colors or fonts — use the
@repo/uidesign tokens. - No ad-hoc mock data in components — fall back to
@repo/db/seed-data. - Env is read through
@repo/env/*, neverprocess.env.Xdirectly.
See CONTRIBUTING.md for the full checklist.