Eagle U — A hundred students matched to fifty mentors in one evening

Built with

Next.js · React · TypeScript · Supabase · Tailwind

Project: Mentor Match

Where it stands

Ran live for around 100 students and 50 mentors in a single evening.
No accounts — students joined by scanning a QR code.
Coordinators watched mentor demand update in real time.
Zero runtime AI calls, so nothing to rate-limit and no key to leak.

The Mentor Match start screen on a phone: first name, last initial, and a group leader picker. — Step one. First name, last initial, group leader — that is the entire sign-up, because the alternative was a hundred teenagers creating accounts in a room with a schedule.

A questionnaire screen asking what kind of work the student is drawn to, with three of eight options picked in order. — The questionnaire. Ranked answers rather than checkboxes — the order is what makes one match beat another.

The interview questions screen: questions written for one specific mentor, each tagged S, W, O or T, with a Download PDF action. — The part that mattered. Questions written for that specific mentor, tagged S/W/O/T so a student can balance what they ask. Mentor names are replaced here.

Before

Eagle U runs a leadership program for high-school students, and one evening of it puts them in front of a room of adult mentors for short interviews. Deciding who should meet whom was happening on paper, in the room, under time pressure — and the students least able to advocate for themselves got the worst matches.

There was a second problem nobody had named: students did not know what to ask once they sat down. A good match is wasted on a conversation that stalls after two minutes.

What I built

A mobile-first web app students reach by scanning a QR code. No account, no password, no app store.

A student answers a short branching questionnaire about what they are interested in and what they want out of the evening. They get back a ranked list of mentors scored out of 100, each with a one-line reason for the match, and drag their top six into an order. Then — the part that mattered most — the app hands them interview questions written for that specific mentor and that student’s stated intent.

Coordinators watch a live dashboard showing which mentors are in demand and which are being overlooked, so they can rebalance the room before it becomes a problem. It exports to CSV.

The decision worth explaining

The obvious way to build this in 2026 is to call a language model when a student submits, and let it do the matching and write the questions.

I did not do that, and the reasons were all constraints rather than principles:

The venue’s wi-fi. A hundred students hitting an API at once, over conference-center wi-fi, on a schedule that cannot slip.
Rate limits. A burst of concurrent requests at exactly the moment the event starts is the worst possible traffic shape.
Cost. The owner’s constraint was explicit — no paid services beyond what was already being paid for.
A key on a public site is a key that can leak.

So the matching weights and every interview question were computed ahead of time, at build. At the event the app is doing arithmetic on data it already has. It responds instantly, costs nothing per student, cannot be rate-limited, and has no secret to expose.

It also degrades honestly: if the database is unreachable the app still runs the questionnaire and shows matches, because the intelligence is in the bundle rather than behind a network call.

After

It ran. Students scanned in, answered, got matches with reasons, and walked into interviews with questions in hand. Coordinators could see the shape of the room instead of guessing at it.

The database tables were namespaced and designed to be dropped after the event, which is not a detail most people would bother with. It matters because an event tool that lingers becomes an unowned system somebody inherits — and the organization should not be maintaining a database for an evening that is over.