Hj HIMANSHU JAIN
← Back to portfolio
Case Study · Product I built & use

Mentor Inbox

A private line between every student and their teacher — where a student raises an issue, books a 15-minute session in the teacher's actual free slots, and the teacher runs the whole thing with clicks, not SQL. Built end-to-end and used live to mentor my own students.

Multi-Teacher SaaS Issue Threads + AI Availability-Driven Booking Teacher Notes PWA + Push
Role
PM + builder, end-to-end
Stack
Next.js · Supabase · Vercel
Status
Shipped · in daily use
01

The problem: mentoring doesn't scale past class hours

A student's real doubts don't arrive during class — they arrive at the study desk, hours later, when the teacher is unreachable. My students were funnelling everything into one WhatsApp number: doubts, exam stress, "sir can we talk," scheduling, all mixed into a scroll I couldn't triage. Nothing was tracked, nothing was private, and "can we talk for 10 minutes" turned into a game of message tag across two days.

The three things breaking, specifically: there was no structured way to raise an issue and see it get resolved; there was no clean way to book a short session without a dozen back-and-forth messages; and I had no memory layer — no per-student notes I could look back on before a call. Mentor Inbox is the tool that replaces the WhatsApp scroll with something a teacher can actually run.

Why build it for teachers, not just me

The same collapse happens to every teacher who mentors at scale. So the app is multi-tenant from the ground up: each teacher gets their own students via a join code, their own inbox, their own slots. I'm the first customer and the proof of concept — but the model is one tool, many teachers.

02

What it does — four pillars

Each pillar replaces one broken part of the WhatsApp workflow. Together they turn ad-hoc mentoring into something structured, private, and repeatable.

Pillar 01 · Admin

No-SQL teacher onboarding

An /admin panel behind a secret creates teacher accounts with a form — name, email, join code (with a Suggest button) — and lists every teacher with their code and student count. No database console, no SQL, ever.

Pillar 02 · Support

Issue threads with AI

Students raise an issue against their teacher and get a tracked, private conversation thread — not a lost WhatsApp message. An AI layer helps draft and triage so the teacher isn't starting cold on every reply.

Pillar 03 · Scheduling

Availability-driven booking

Students book 15-minute sessions — but only in slots the teacher has explicitly opened. Nothing is bookable by default. First-come-first-served, one student per slot, with a reason note attached.

Pillar 04 · Memory

Teacher notes

Per-student notes the teacher owns, working for both signed-up students and manually-added ones (name + batch, no login). Generates a per-student report before a call.

03

The hard part: booking that respects real availability

Most booking tools get this backwards — they show every slot as open and make you block the ones you can't do. For a teacher that's exhausting and error-prone. Mentor Inbox inverts it: nothing is open until the teacher opens it. A student only ever sees the exact slots their teacher deliberately made available.

TEACHER opens slots by day-toggle or range ALLOWED WINDOWS Mon·Tue·Thu·Fri 11–3 Sat 3–5 · Sun 3–4 no Wednesday → split into 15-min slots STUDENT books a free slot + reason note PUSH to teacher Only teacher-opened slots ever reach the student
Slot lifecycle — teacher availability is the gate, not the exception

The allowed windows are enforced in a shared rules helper, so the teacher UI can't open an illegal time. The teacher opens slots two ways — toggle a whole day's window on, or open a specific range that auto-splits into 15-minute slots — and can remove any individual slot. Booked slots show as taken to other students (greyed, no name), and a student can cancel up to 2 hours before.

WindowDaysRule
WeekdayMon · Tue · Thu · Fri11:00 AM – 3:00 PM · Wednesday excluded entirely
SaturdaySat3:00 PM – 5:00 PM
SundaySun3:00 PM – 4:00 PM
Slot sizeall15 minutes · one student per slot · booked with a reason note
04

Build decisions — where the interesting tradeoffs were

The happy path is easy. The decisions that shaped the build were about security, integrity, and modelling messy reality — each one a product call, not just a coding one.

ChallengeWhat breaks the naive versionThe decision
Creating accounts Account creation needs admin privileges that can't sit safely in the browser Server-side admin route protected by a secret only the owner knows — privileges never reach the client
Booking integrity Two students could race to grab the same slot, or book a slot as someone else Database trigger enforces the rules — a student can only book as themselves, only a genuinely free slot
Off-app students I mentor students who never signed up — there's no record to attach notes to Manual students (name + batch, no login) — notes-only, merged into one picker so it feels seamless
Notifying on booking Bookings happen via a slot update, so the message-webhook never fires A second webhook on the slots table routes booking events into the existing push system
Reach past class hours A web page a student has to remember to open is a web page they forget PWA + push — installable, and the teacher gets notified the moment a student acts
05

The stack, and why each piece

Framework
Next.js — app routes double as the secure server-side admin API
Data + Auth
Supabase — Postgres, row-level rules, and triggers that enforce booking integrity in the DB itself
Deploy
Vercel — GUI-only workflow, env-var secrets, auto-redeploy on push
Delivery
PWA + web push — installable app + real-time teacher notifications

Every secret — the admin password, the Supabase service-role key — lives server-side in Vercel env vars, never in the browser. The booking rules aren't trusted to the frontend either: they're a Postgres trigger, so integrity holds even if someone hits the API directly.

06

What building this taught me

  • Model reality, not the ideal. The manual-student feature exists because real mentoring is messy — students I coach who never signed up still need a record. A tool that only handles clean cases doesn't get used.
  • Put integrity where it can't be bypassed. Booking rules live in a database trigger, not the UI. Security and correctness belong at the layer nothing can route around — a product decision, not just an engineering one.
  • Invert the default when the default is exhausting. "Nothing is open until you open it" turned scheduling from a chore into two taps. The right default is the one that respects the busiest person's time.
  • Be the first user. I use this to mentor my own students, so every rough edge is one I feel. That feedback loop is faster and more honest than any user interview.
See it

Mentor Inbox is an active build I use to mentor my own students. Teacher accounts are provisioned via the admin panel; the student experience is behind a per-teacher join code.