Technology School — Role-Based Learning Platform
One platform, three different people signed in — student, parent and instructor each see a different product.
Published anonymously at the client’s request
Overview
A learning portal for a three-year structured technology school teaching ages 6 to 17. Students track their own grades and sessions, parents watch their child’s progress and manage the subscription, and instructors record grades, write private notes and message families — all from one authenticated application.
What this proves
That we ship authenticated, multi-tenant product — not marketing pages. Three role surfaces over one schema, with live presence and messaging.
Key features
Three dashboards over one schema
Student, parent and instructor each get a distinct dashboard reading the same ten tables. A parent sees their child’s grades and attendance but not the instructor’s private notes; an instructor sees a roster but not another family’s billing. The role is resolved once at sign-in and drives every subsequent query.
Messaging with live presence
Threaded messages between families and instructors, with a presence table so the other party shows as online while they are in the app. The thread view reflows into a single-column layout on phones rather than shrinking the two-pane desktop arrangement.
Subscription requests and enrolment
Age-banded programme tiers — 6 to 9, 10 to 13, 14 to 17 — feed a subscription request flow with a card-details screen, so a browsing parent becomes a reviewable application rather than an email.
Dark and light themes on one token set
Both themes are declared as two complete colour objects and swapped at runtime, so no component hard-codes a colour and the light theme is a genuine redesign of the palette rather than an inverted dark one.
Grades, notes and achievements
Instructors record per-session grades that roll up into an average, attach private student notes, and award achievements — with notifications delivered to the right role.
The problem
A structured three-year curriculum across three age bands generates a lot of state that families expect to see: which sessions a child attended, what they scored, what the instructor actually thought, what is owed. Most schools of this size run that on a group chat and a spreadsheet, which means the answer to “how is my child doing?” depends on who is awake.
The brief was to put that behind a login instead — one record of truth, three audiences, each seeing exactly what belongs to them.
Engineering
Supabase provides authentication, the PostgreSQL schema and file storage for avatars, so there is no server of ours to operate. Ten tables carry the domain: profiles, sessions, grades, student notes, achievements, messages, presence, notifications, subscription requests and avatars. The client resolves the signed-in profile once and every dashboard is a projection of that role over those tables.
Motion is handled by anime.js rather than a React animation library — staggered letter reveals on the landing page, counting statistics, and a scanline treatment on the hero. It is a deliberate choice for a single-bundle Vite app: the animation layer stays outside React’s render cycle entirely.
Not demonstrated by this project
Stated plainly, because a portfolio is more useful when it is precise about its limits.
- The application is a single component file — it is not modularised
- No automated tests of any kind
- The card screen collects details but no payment processor is integrated
- English only — no Arabic interface, despite the audience
- Access control is enforced in the client; database-level row policies are not evidenced here
- No server-side rendering or SEO surface — it is an application, not a site
Portfolio assessment
- Visual design
- 7.0 / 10
- Technical complexity
- 7.0 / 10
- Interactivity
- 7.0 / 10
- Business value
- 8.0 / 10
- Portfolio appeal
- 7.0 / 10