Development
The shortest path to understanding how the app is organized and where new product code belongs
Development
Purpose
Show where new code should go so adding features stays boring and local.
The repo shape
app/owns routes onlyfeatures/owns product behavior by domaincomponents/owns shared UIlib/owns infrastructureconfig/owns app-wide configprisma/owns schema, migrations, and seed
Read this as the default rule
app -> features -> lib
Keep route files thin. Put product logic in the owning feature.
Where to copy patterns from
The tasks feature is the cleanest end-to-end example in the repo.
It shows:
- route surface
- server data loading
- server actions
- Zod validation
- data table UI
- plan gating
Start here:
app/(app)/dashboard/tasks/page.tsxfeatures/tasks/
Adding a new feature
Use this sequence:
- Add the route in
app/. - Create the feature folder in
features/your-feature/. - Keep server logic, schema, and UI close to that feature.
- Only add shared code when it is truly shared.
Forms and actions
Most interactive flows already use server actions and useActionState.
Before creating a new form pattern, copy an existing feature and keep the same conventions.
Database work
Edit the Prisma schema, run a local migration, then update the owning feature.
Do not create parallel internal types for the same concept unless you are crossing a real boundary.