TutorLink

The problem

Matching students with the right tutor is a search-and-fit problem before it's anything else: subject, availability, and some notion of quality all have to line up — and the data shape for "what actually matters in a good match" is exactly the kind of thing that keeps changing once real people start using it.

Why MERN

Keeping the whole stack in JavaScript — React on the frontend, Express and Node on the backend, MongoDB underneath — means one mental model end to end: one language, one set of async idioms, one type story if I lean on TypeScript throughout. MongoDB's schema flexibility is the more specific bet: tutor and student profiles, availability, and matching criteria are the parts of this app most likely to grow new fields as the matching logic gets smarter, and a document store lets that evolve without a migration every time it does.

Where it stands

The core CRUD layer — accounts, profiles, session records — is built. What's actively being worked on is the matching logic itself: turning "subject + availability + rating" into a ranked shortlist instead of a plain filtered list. Session scheduling and any kind of booking/payment flow are deliberately still ahead of this, not behind it.

What's next

Finish a first real version of the matching algorithm, then wire session scheduling up against real tutor availability data.