Extension Workflow
This starter is opinionated about how new features should be added. That is part of the product value.
The goal is not to freeze the architecture. The goal is to let teams extend it without turning the repo into a pile of cross-cutting exceptions.
Expected Workflow
- Define or extend the data model in the backend package.
- Add validated Convex handlers with server-side auth checks.
- Introduce permissions or capabilities only when the feature needs them.
- Add routes and UI in the correct surface inside
apps/app. - Validate the feature with tests or a clear verification checklist.
Important Structural Rules
- backend source is authored in
packages/backend/convex - surface-specific UI stays in the owning route tree
- shared packages exist for true cross-app contracts and infrastructure
- capabilities are for product-area gating, not every minor conditional
Why This Matters To Buyers
- the starter gives you a growth path, not just a starting snapshot
- new features can be added without blurring org, portal, and platform concerns
- permission and capability boundaries already have a place in the architecture
Good Signs During Evaluation
- a new feature can be located in one owning surface quickly
- backend logic has a predictable home
- access rules do not require duplicating logic across frontend and backend
- shared code moves into packages only when reuse is real