Case study · Education

Growtrees Portal.

A web platform for Growtrees Education Centre, a tuition centre. Admins, teachers and students each sign in to their own workspace for classes, timetable, attendance, learning materials, rewards and notices. It works on phones, tablets and computers.

Client
Growtrees Education Centre
Users
Admins, teachers, students
Delivered
Design, build, hosting setup, ongoing releases
Stack
Next.js, TypeScript, Supabase, Vercel

This page describes what the portal does. It includes no performance figures, client results or private user data.

Background

One centre, many daily routines.

A tuition centre runs on many small routines: putting students into classes, keeping the timetable current, taking attendance, sharing worksheets, recording lunches and keeping students informed. Each role needs to see a different part of that picture.

The brief was one system for all three roles. Each person sees only what their role allows, and the centre's own staff handle day-to-day management without technical help.

  • Separate workspaces for admins, teachers and students
  • Usable on the phones and tablets staff already carry
  • Learning materials that stay inside the centre
  • Changes requested by the centre added in small, tested releases

What the portal does

Built around the centre's real workflows.

  • Classes & timetable

    Branches, courses, classes and enrolments in one place. Recurring timetable entries, with one-off changes per class: cancel, change the teacher, reschedule or restore. Public holidays show which classes they affect.

  • QR attendance

    Teachers start a class session and scan each student's personal QR code with a phone camera, or mark students manually. Sessions can be completed and reopened, and students see their own attendance history.

  • Learning materials

    Only admins upload, edit or remove materials. Teachers and students see only the materials for their own classes. Files open through short-lived secure links instead of public URLs.

  • Community stories

    Admins and teachers post class stories with photos and video, saved as drafts until published. Students see published stories meant for them.

  • Rewards

    Staff award points and record redemptions from a reward catalogue. Every change is a new ledger entry, so a balance can always be traced back to how it was earned and spent.

  • Daily operations

    Meal tracking for each student, each day, and a daily task checklist for teachers, both kept to Malaysian dates.

  • Notifications & email

    In-app notices with matching emails. Scheduled jobs send class reminders, attendance reminders and birthday wishes.

  • Built, awaiting release

    Homework with teacher marking, private report-card comments, moving classes online on haze days, and class comments with @mentions. These are built and tested on the staging environment and go live in the centre's next production release.

Management flow

From setup to a normal teaching day.

  1. Set up

    Admins add branches, courses, teachers and students. New users receive an email invitation and set their own password.

  2. Schedule

    Classes are created, students are enrolled, and the timetable and holidays are maintained by admins only.

  3. Run the day

    Teachers see today's classes, take attendance by QR, record meals and work through their daily tasks.

  4. Share & inform

    Materials, stories, rewards and notices reach the right students, and each role sees only their own classes.

Architecture & engineering

Permissions enforced at every layer.

  • Next.js App Router
  • React
  • TypeScript (strict)
  • Supabase Auth
  • PostgreSQL + RLS
  • Supabase Storage
  • Vercel + Cron
  • Vitest + PGlite
Access control
Each permission is checked three times: in the interface, in the server action or API route, and in PostgreSQL row-level security. The browser is never trusted with a role decision.
Data model
One migration chain shared by staging and production. Constraints and triggers protect rules such as an append-only points ledger and one meal record per student per day.
Files
Materials and story media are kept in private storage buckets and served through signed links after a role check.
Scheduling
One shared resolver works out every class occurrence, including overrides and holidays, so the timetable, reminders and attendance always agree.
Testing
Automated tests run database policies, server actions and API routes against an embedded PostgreSQL. CI runs type checking, linting, tests and a production build on every push.
Releases
Changes go to a staging environment with synthetic data first. Production releases are approved by the owner, with the previous deployment kept ready for rollback.

Our role

What BrightLayer Labs did.

  • Product and workflow design with the centre, per role
  • Interface design and responsive front-end build
  • Database schema, row-level security and storage rules
  • Server actions, API routes, scheduled jobs and email notifications
  • Automated test suite and CI pipeline
  • Staging and production environments on Vercel and Supabase
  • Ongoing releases that work through the centre's feedback list

For tuition & education centres

Need something similar for your centre?

We can start with the one routine that takes your team the most time, such as attendance, timetable changes or sharing materials, and scope from there. You don't need to commit to a full portal on day one.

Tell us how many branches and students you have, which tools you use today, and which routine you want to fix first. Please do not send passwords or student data.

Discuss a portal for your centre Or start with a workflow review