MentorMatch — Mentor Platform (test build)

A working prototype of the mentor booking platform described in the requirements: mentees browse mentors, filter by tags, book an open slot, pay, and get a meeting link once the mentor accepts.

Built with Next.js 16 (App Router) + React 19. No database is required — data lives in an in-memory store (lib/db.js) seeded from lib/seed.js, so the app runs with zero setup. Payments and payouts are simulated.

Run it

npm install
npm run dev      # http://localhost:3000

npm run build && npm start for a production build.

The in-memory store resets every time the server restarts (fresh seed data).

Where to click

Page	Route	What it does
Directory	/	Grid of mentor cards + all filters (main screen)
Mentor profile	/mentors/[id]	Full details, bio, availability, booking panel
My bookings	/bookings	Mentee's bookings, status, meeting link
Mentor console	/mentor	Set availability, accept/decline requests (pick which mentor you act as — no login in this test build)

How the build maps to the requirements

1. User roles — Mentee flow (/, /mentors/[id], /bookings) and Mentor flow (/mentor). No login in the test build; the console has a "acting as" mentor picker.
2. Mentor directory — Card grid with name, photo (initials avatar), industry, working status, availability ("next slot" + open-this-week count), meeting mode, years of experience, university, company, last title, and support-area tags.
3. Filtering — Any combination of industry, working status, meeting mode, experience range (min/max), university, and support areas (multi-select). "Both" mentors match Online/In-person requests.
4. Mentor profile page — All tags in detail, bio, open-slots-only availability, per-slot "Book".
5. Booking flow — Select slot → simulated payment (authorize) → booking is pending → mentor accepts/declines. On accept, a meeting link is shared to both parties; on decline, the mentee is refunded and the slot released.
6. Mentor availability — Add/remove open time blocks (datetime-local). Booked slots disappear from mentee view and can't be removed until resolved.
7. Payments — Authorized at booking, captured only after the mentor accepts (avoids refund complexity on decline). Payouts are manual/out of scope.
8. Meeting link — Shared on acceptance (static per-mentor link, with a generated fallback).
9. Out of scope — No ratings/reviews, chat, recurring bookings, automated payouts, or mobile app, as specified.
10. Definition of Done — ✅ A mentee can filter mentors, view a profile, book an open slot, pay, and once the mentor accepts, both parties receive a working meeting link. Verified end-to-end.

Project structure

app/
  page.js                     directory + filters
  mentors/[id]/page.js        profile + booking
  bookings/page.js            mentee bookings
  mentor/page.js              mentor console
  api/
    mentors/route.js          GET list
    mentors/[id]/route.js     GET one
    mentors/[id]/slots/route.js  POST add / DELETE remove availability
    bookings/route.js         GET (by mentor/mentee) / POST create
    bookings/[id]/route.js    PATCH accept | decline
components/  Avatar, PaymentModal
lib/         db.js (store), seed.js (data), format.js (helpers)