About this prototype
This shows the flow from Jesse's design notes (12 October 2026) working end to end, so it's easier to react to than a document. The people are made up. Everything you change is saved only in your browser, and Reset demo puts it back to the start.
What is real and what is simulated
- The matching follows the notes: serving ones are matched to older shepherds first, then students to shepherds and any older shepherds left over. Pairs are always the same gender and never from the same locality.
- Push notifications are simulated. The banner and inbox on the phone show what each person would receive.
- The spreadsheet is a CSV file that opens in Excel or Google Sheets. A real build could export .xlsx.
- The registration database is the list under People and shepherds. In the real app it would come from the registration system.
Guesses that need Jesse's answer
- More serving ones than older shepherds. Anyone the matching can't place goes on a "Not matched" list for the registration team to handle by hand. Should serving ones fall back to ordinary shepherds instead?
- No valid partner. If the only shepherd left is from the same locality, the person stays unmatched rather than breaking the rule. Should the matching relax the locality rule as a last resort?
- One person per shepherd per slot. Could a shepherd see two or three people at one meal?
- One appointment per person. Once a student or serving one has an appointment, they aren't matched again in later slots, and their other slots are greyed out. Is that right, or can people book more than one?
- Where to meet. Each slot has one set of meeting instructions, and each pair gets a table number. Is that how it works at the conference?
- People left without an appointment. They don't get a notification. Should they be told, and offered another slot?
- Shepherds' time. Shepherds can offer as many slots as they like.