Role-Based Dashboards for Teachers, Students and Parents
Three users, three different questions
A student opens the app asking 'what do I learn next?'. A teacher asks 'who is stuck?'. A parent asks 'is my child actually working?'. A single dashboard answering all three answers none of them well, so Kilele Archade ships one application with three distinct surfaces over the same data.
The role model
Roles attach at the relationship level, not just the account level: a teacher belongs to a class, a parent is linked to specific students, a student is enrolled in subjects. Every request resolves what the caller can see through those links before any content query runs.
Enforcing it with row-level security
Rather than trusting application code alone, visibility lives in Supabase policies: rows carry their class and linkage, and the database refuses reads that do not match the caller's role claims. A bug in one endpoint cannot turn into a data leak across the platform.
The privacy boundary nobody mentions
A parent should see that a child is engaging and progressing — not every answer they got wrong in a private study session. The dashboards were deliberately asymmetric: learners get granular self-view, guardians get aggregated signals, teachers get class-level detail. Same events, three zoom levels.
What I would reuse
Relationship-scoped roles, database-enforced visibility and zoom-level dashboards are not EdTech-specific. Any multi-sided product — clinics, gyms, tutoring, PropTech rentals like Apex — needs exactly this skeleton, and designing it early is much cheaper than retrofitting it after the first privacy conversation.