The problem
The club needed to answer basic historical questions—what had been tasted, who won, what people thought, which bottle was most wanted—without relying on one person to remember fifteen years of history.
It also needed to run a live blind-tasting event from setup through serving, voting, guessing, reveal, comments, and results without making everyone stare at a complicated app instead of enjoying the night.
Architecture follows the club
One of the governing rules is simple: the app models the club; the club does not change to fit the app.
- Participant, Steward, and Host roles receive different responsibilities and interfaces.
- Blind sample codes protect the reveal workflow.
- Results are generated from recorded votes rather than manually “voted into” existence afterward.
- Memories and curated Lore are separate so casual recollections do not silently become permanent club history.
- The Steward path stays deliberately minimal because the person serving whiskey should not need to become the event's system administrator.
The hardest requirement is social, not technical
A live event has a very low tolerance for friction. Every extra field, navigation step, or ambiguous state competes with the actual reason people gathered. That makes workflow design, role clarity, and recovery from partial participation more important than adding more features.
Why it stays private
The repository and production data contain club-specific logic, member history, private collections, event details, and social context. The public value is in the product reasoning and workflow design—not in exposing the people or their data.