Mentor matching that used to live in a spreadsheet
iMentor is a CMS-driven education platform where coordinators, mentors, mentees and admins each get their own view of the same programme. Content, cohorts and progress all run through the CMS.
Its centre of gravity is matching. Pairing mentors to mentees was a manual, spreadsheet-driven exercise; here it is an algorithm over availability, subject, capacity and preference, with coordinators keeping final say.
Once paired, they stay inside the platform: mentor and mentee talk over built-in chat, so the conversation is part of the programme record rather than scattered across personal WhatsApp threads.
Subject fit, availability overlap, mentor capacity and stated preference all matter, and they conflict. Each pairing gets a weighted score with the reasoning exposed, so coordinators can see why a match was proposed and override it.
Every endpoint means something different per role. Permissions are declared per resource and enforced in one middleware layer rather than scattered through handlers, which kept the surface auditable as roles grew.
Assignment respects per-mentor load limits inside the allocation pass, so a strong-fit mentor never quietly ends up with eight mentees while others sit idle.
A socket connection is not a record. Every message is persisted before it is broadcast, so history, unread counts and delivery state all rebuild from the database when a mentee reopens the app on a different device.