What it does
The directory, the request, and the thread between them
Six parts of the product, described without adjectives.
Six decisions the product makes
Roles are set at signup
Student and professor accounts are separate from the first screen, and only an admin can change a role afterwards.
A request, not a blank email
Every request carries three fields — topic, academic background, and goals — so a professor sees the context before deciding.
A person reviews every professor
An admin checks each professor application before the profile joins the directory. Nothing appears there unreviewed.
Group requests
Work on one request with classmates. Everyone is on the same thread, and the professor can see that it is a group.
One thread per request
Messages, replies and unread markers live in the request's own thread, so a conversation cannot drift into an inbox.
States, not silence
A request moves through named states — open, active, declined, past — so you can tell waiting from decided.
Who can read a thread
Row-level security is on for the tables that hold your data, so a request is readable by the student who sent it, the faculty member it was sent to, and the participants they invited. Not by anyone else, and not by us in a browser console.
How that is enforced
Gated before it renders
Signed-in pages are turned away at the edge when there is no session, and server actions re-check the caller rather than trusting the page that called them.
Roles come from the database
Your role is read from your own profile row on the server. Nothing the browser sends can promote an account.
Start with one professor.
Free for students and faculty.