Winter 2022 · University of Toronto · Six-member academic team
GDSC UTM Application Portal
A club portal, built as a team
Our six-person team built a portal for club applications, mentors and project teams. I worked on access and member-facing features, including login and superuser access.
My part
I contributed login, registration connections, bug reporting and superuser access. We used shared design documents, sprint planning and issue tracking; the sprint records link login and superuser tasks to me.
Across the stack
React handled the frontend, with Node.js and Express routes behind it and MongoDB for data. JWT supported authentication. Access features meant connecting what a person sees with the routes, validation and permissions behind the screen.
Project context
This was a Winter 2022 University of Toronto team software project for GDSC. It gave us a shared application to work on, with features that had to fit together. It wasn’t employment with Google or a commercial release.
Reading the archive
The image is from the historical club website, not a running portal demo. The repository needs a dependency, configuration and security review before a new deployment. There’s no current live service to link here.
The hard part
An access feature crosses more than one screen. The interface, server routes and stored data have to agree about who can do what. Shared sprint records gave our team a way to divide that work without treating every layer as one person’s contribution.
What I’d revisit
Before bringing the archive online again, I’d review dependencies and configuration, document setup and add reproducible access-control checks. The repository is evidence of the team project, not a service I’m claiming to operate today.
Continue under the hood
A feature has more than a happy path
Read the sprint assignment beside the route
The sprint records name my work on login, the registration connection, bug reporting and superuser login. The team repository shows the wider React, Express and MongoDB implementation.
Those two kinds of evidence answer different questions: what I was assigned, and how the shared application was structured. Neither makes every commit mine.
A review checklist for the old implementation
For registration: duplicate email, missing fields and a response on every branch. For bug reports: who can create, edit or resolve one, and whether the server checks that permission.
These are checks I would run before reviving the course project, not a claim that the archived version already passes a modern security review.