04 — Multi-Tenant Client Portal

Multi-tenancy is the architectural challenge. Client A must never see Client B's data. GraphQL makes data isolation more interesting — you enforce tenant scoping in every resolver, not just every route. Harder than the booking platform because of three distinct roles, organizational hierarchy, and the deliverable review workflow.

What to Build

Three roles: Agency Admin (sees everything), Agency Staff (assigned to specific clients), Client User (sees only their org's data)
Organization setup: agency creates client orgs, invites client users
Projects per client: phases/milestones, status, deadlines, assigned staff
Deliverables: link URLs per project. Status workflow: In Progress → Submitted → Approved / Revision Requested. Revision history with notes.
Threaded messaging per project and per deliverable. No cross-client visibility.
Client dashboard: active projects, deliverables awaiting review, recent messages, deadlines
Agency dashboard: all clients overview, projects by status, overdue items, staff workload
Activity log: timestamped feed per project
Data isolation: every resolver scoped to user's organization. Non-negotiable.

Decisions You'll Make

How to enforce tenant isolation in GraphQL resolvers (middleware? wrapper function? check in every resolver?). How to design the schema so a single query can fetch a project with its deliverables, messages, and assigned staff. How to model the deliverable review workflow as mutations (submitForReview, approve, requestRevision). Whether to use GraphQL subscriptions for real-time message updates or polling.

Stack

GraphQL Apollo Server Apollo Client React Node.js MongoDB Mongoose JWT React Router useContext Custom Hooks Vitest Playwright Material UI