Skip to content
FLANERY
← Flanery Solutions

A youth leadership program · 2026 · Education · live event

Matching a hundred students to fifty mentors, live, on venue wi-fi

One evening, fifty mentors, a hundred students, and no good way to decide who should talk to whom. Students now answer a short questionnaire and get a ranked shortlist with a reason for each match — and the whole thing runs with no AI calls, no accounts and no login.

This client hasn’t been asked yet whether they’re happy to be named, so they aren’t. Everything else here is exactly as it was built. If you want a reference before hiring me, I’ll ask them.

Built with

Next.js · React · TypeScript · Supabase · Tailwind

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.

Before

The event puts students in front of 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-centre 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 organisation should not be maintaining a database for an evening that is over.

If any of this sounds like your operation, the first call is free.

Ask for a call