Building Dram: A Conversational Whisky Recommender That Starts With Taste
Dram is a conversational whisky recommender for people who know what they enjoy but may not know the language of whisky. Instead of beginning with regions, cask types, or bottle names, the assistant asks about familiar preferences: espresso, apple pie, salty snacks, rainy evenings, or a dinner shared with friends.
The result is a shortlist of three bottles, each paired with flavour cues and a plain-language explanation of why it fits. The aim is not to replace personal taste with a score. It is to translate a person’s own words into a useful starting point for discovery.
From Everyday Language to a Flavour Profile
Conversations are converted into a structured profile across sweetness, smoke, richness, fruit, and spice. The profile also records descriptive clues such as coffee, citrus, oak, caramel, or coastal notes. This gives the recommendation step a stable representation of taste without forcing the visitor to fill in a technical questionnaire.
Follow-up messages refine that profile. Someone can start with a meal, add a remembered bottle, or reject a smoky direction, and the next shortlist can adapt while keeping the reasoning visible.
Recommendations That Explain Themselves
The catalogue combines bottle metadata with flavour vectors derived from public whisky-review data. The assistant selects from that constrained catalogue rather than inventing products, and every recommendation includes the bottle’s region, dominant flavour notes, and a short explanation tied back to the conversation.
Each result card is designed to answer two questions quickly: “What is this?” and “Why does it suit me?” A visitor can then ask about a specific bottle and continue the conversation without restarting the process.
Two Engines, One Consistent Experience
The application can run through a conventional language-model flow or an optional TypeSafe JEV engine. Both paths produce the same validated response structure, so the interface can render recommendations, flavour profiles, follow-up suggestions, and run-cost information consistently.
That separation makes the product useful as more than a recommendation demo. It is also a compact environment for comparing two approaches to turning a nuanced conversation into dependable structured output.
Credentials Stay on the Server
The browser never receives the Groq or TypeSafe API keys. They are loaded from server-side environment variables and used only by the FastAPI application when it contacts the model providers. The public HTML, JavaScript, generated metadata, and image assets contain no credentials.
The API also validates message length and request shape, rejects cross-site write requests, disables response caching for conversation endpoints, and adds restrictive browser-security headers. Conversation data is kept in SQLite rather than being embedded in the frontend.
A Focused Product, Not a Tasting Exam
Dram’s most important design choice is its starting point. People should not need whisky expertise to receive a thoughtful recommendation. By meeting them in the language they already use for food, mood, and memory, the interface makes a complex catalogue feel approachable without flattening the differences between bottles.
If you are exploring a recommendation experience for a specialist catalogue—or want to see how conversational input can become structured, explainable product suggestions—get in touch below.