Product Vision
The product vision, domain model, and core concepts behind VJA Start.
What is this product?
The portal is a project management application for a fictional company. It covers the full lifecycle of projects, tasks, teams, and clients. The domain is deliberately simple and universally understood.
The domain is there to teach. The code underneath it is what you reuse.
Why this product?
This monorepo exists to demonstrate full-stack patterns end to end. That needs a product complex enough to justify:
- Authentication with role-based access control
- Chart dashboards with stat cards and trends
- Data tables with sorting, filtering, and bulk actions
- Drag-and-drop kanban boards with custom columns
- Multi-step wizard forms with many input types
- Activity timelines with keyboard navigation
- CMS-driven marketing pages with animations
- Detail pages with nested routes and health tracking
A todo app cannot do this. A project management app is the simplest domain that naturally requires all these patterns.
Domain model
The product manages projects for clients. Each project contains tasks assigned to team members.
Roles
| Role | Description |
|---|---|
| Super Admin | Full access. Manages which permissions each role has. |
| Admin | Manages projects, tasks, members, clients. No role permissions. |
| Manager | Manages tasks and members. Can view projects and clients. |
| Member | Works on own tasks. Can view projects, members, and clients. |
Example data
- Projects: "Website Redesign", "Cloud Migration", "Mobile App Launch"
- Tasks: "Design homepage mockup", "Set up CI/CD pipeline", "Write API documentation"
- Teams: "Engineering", "Design", "Operations"
- Clients: "Acme Corp", "Globex Industries", "Initech Solutions"
Apps
The product is split into five apps:
| App | Purpose | Audience |
|---|---|---|
apps/portal | Main app: auth, dashboard, team, projects | Employees |
apps/api | Backend REST API (NestJS + Fastify) | Portal, mkt |
apps/marketing | Public landing pages, pricing, highlights | Prospects |
apps/docs | Documentation site (renders docs/ md) | Developers |
apps/e2e | Playwright end-to-end tests across the apps | Developers |
Implementation scope
The feature map is the current list. It marks which features are built across frontend and backend and which are still specs. The built ones cover auth, dashboards, data tables, kanban boards, forms, activity logs, and CMS-driven pages.
The rest have detailed specs in docs-dev/features/, which serve as blueprints for developers who want to practice building from requirements.
Building your product on this repo
The repo you cloned is the application. Your product grows out of it by editing what is already there, so there is no generator to run first and no thinner starter to produce.
apps/portal and apps/api are where your product lives. Projects, tasks, clients, and team members are the reference domain: rename them into yours, or add your first feature beside them following the same folder structure. Keep the reference features while you build, so an agent working under the .claude/ rules has an on-pattern example to copy, and retire each one once your own code has replaced what it was showing you.
packages/ and .claude/ are product-agnostic and carry over unchanged. You rebrand apps/marketing through the Payload admin, and rewrite docs/ for your product.
The README's Making it yours section lists what to change on day one, in order.