Very Hungry Tourists

The Problem

Travelling to an unfamiliar city and finding food that genuinely fits your preferences — dietary needs, budget, mood, distance — is a surprisingly frustrating experience.

Google Maps returns everything, flooding users with choices. TripAdvisor buries local spots under heavily marketed tourist traps. Neither explains why a result fits you specifically.

The gap is not data. Every major city has abundant restaurant data. The gap is reasoning. No existing tool takes a set of personal constraints — "I am vegan, I have €20, I am near the city centre, I want Chinese food but I'm curious what the local version tastes like" — and returns three restaurants with a specific, honest explanation of why each one fits.

That reasoning gap is what Very Hungry Tourists fills.

Two Distinct User Intents

Early in the design process I identified that food discovery for travellers has two fundamentally different emotional states, requiring two different product flows:

1. Intent 1 — "I'm eating out today": Low planning horizon. The user is in the city, they have preferences, they want a decision in under 3 minutes. The job: reduce decision fatigue right now.
2. Intent 2 — "I'm planning a trip": High planning horizon. The user is preparing a trip, they have a budget, they want to feel confident about their meals before they arrive. The job: give me a strategy, not a list.

A single homepage with one search bar fails both. The product homepage presents two distinct paths with copy that matches how users actually think about their situation: "I'm eating out today" and "I'm planning a trip." Each path leads to a different flow, optimised for its specific emotional state.

This two-path architecture is the central product decision. It prevents the most common failure mode in food discovery apps: building a tool that is adequate for every usecase and exceptional for none.

The Human Anchor

The product was shaped by a specific observation: a friend who relocated to France to study the language and culture found that food was her fastest route into the community — but discovery was overwhelming. Knowing what a city is famous for, understanding how immigrant food cultures shape the local scene, finding places that locals actually eat rather than places that rank well on tourist aggregators — none of the existing tools answered those questions.

That human anchor drove every design decision. The Accra inclusion in the city rotation on the homepage (alongside Montpellier and Athens) is a deliberate product choice, not a content decision — it signals that this tool is not built for Western tourists only.

Flow 1 — Instant Discovery

The discovery flow collects five parameters through a clean, low-friction interface: location preference (close to me vs willing to travel), mood/cuisine type, dietary requirements, maximum budget, and budget flexibility toggle.

On submission, a Gemini 1.5 Flash API route builds a structured prompt injecting all five parameters alongside a system instruction that enforces strict filtering logic: restaurants that do not meet ALL dietary requirements are eliminated regardless of quality. Budget flexibility allows up to 15% over the stated maximum only if the value proposition is significantly higher — and the AI must state why it stretched the budget in the insight text.

The route returns exactly three results as structured JSON. Three is a deliberate product constraint, not a technical one. Research on choice paralysis is clear: beyond five options, decision quality drops. For a user who wants to eat now, three curated picks with reasoning is the right answer.

The AI Concierge Insight is the core value proposition. Each restaurant card surfaces a 2-sentence personalised explanation — not a generic review summary — that directly references the user's filters: "This spot offers five distinct vegan seafood alternatives for under €15, matching your budget flexibility perfectly." The insight transforms the product from a filter tool into an intelligent concierge.

Flow 2 — Trip Planning

The itinerary flow solves a genuinely hard multi-constraint optimisation problem: given a total food budget for a group over multiple days, build a day-by-day meal plan that sequences local discovery, comfort cuisine cross-referencing, neighbourhood proximity, and a single elevated splurge dinner — all within budget.

The budget logic treats the total pot as a single resource distributed intelligently across the trip:

• Breakfast: Approximately 15% of daily budget (café culture, light eating).
• Lunch: Approximately 30% (sit-down, not extravagant).
• Splurge Dinner: Up to 40% of the entire trip budget.
• Other Dinners: Good but economical.

The AI verifies budget compliance before output and must degrade gracefully when constraints are tight — introducing local market stalls and street food rather than fabricating expensive restaurant data.

The comfort cuisine feature addresses a specific and underserved traveller curiosity: what does a familiar cuisine look like in this city? Montpellier has a large North African community; its couscous scene is distinctly different from Paris or London. A traveller who loves Chinese food is curious what Chinese food tastes like when it has absorbed southern French influences. The AI places exactly one comfort cuisine meal across the trip — always at lunch on Day 2, never on Day 1 (which should be pure local discovery) and never at the splurge dinner slot.

The generating state is designed to make the AI feel intelligent rather than slow. Rather than a spinner, it shows a sequential list of what the AI is actually doing — "Finding what Montpellier is known for… Calculating your €100 budget across 3 days… Sequencing your meals by neighbourhood" — with each step checking off as it completes. This is a UX decision with a responsible AI rationale: users should understand what an AI system is doing on their behalf, not just receive an output from a black box.

The AI Architecture

Instant Discovery route (`/api/recommend`): Receives the five filter parameters, calls Gemini 1.5 Flash with Google Search grounding enabled, and returns a JSON array of three restaurant objects. Google Search grounding ensures recommendations reflect real, currently operating restaurants rather than hallucinated ones — a critical reliability requirement for a tool people use to make real decisions.

Itinerary route (`/api/itinerary`): Receives city, duration, party size, total budget, dietary needs, comfort cuisine, and language preference. It applies the budget distribution model, splurge dinner logic, and comfort cuisine sequencing rules through the system prompt. It returns a structured JSON object with trip narrative, day-by-day meal plan, per-meal estimated costs, and a running total enabling the frontend budget tracker.

Citation stripping is applied to all string fields in both routes before returning to the client, removing Google Search grounding citation markers that would otherwise clutter the user-facing insight text.

Both routes return warm, informative fallback responses on failure rather than exposing raw API errors.

The Responsible AI Consideration

Food recommendation systems carry a non-obvious bias risk: they tend to surface well-reviewed, tourist-facing establishments over locally-owned, community-embedded restaurants — partly because those businesses generate more structured data online and therefore rank more highly in training corpora.

I addressed this through explicit prompt engineering. Both the discovery and itinerary system prompts instruct the model to prioritise authenticity signals alongside rating data, to surface local and minority-owned venues, and not to default to the highest-review-count tourist spots. The "Local Favourite" vibe tag in the discovery results is AI-generated based on review sentiment that specifically identifies community endorsement signals rather than tourist volume.

A fuller solution would involve auditing recommendation distribution across restaurant ownership types — something I have designed for v2. The responsible AI consideration is documented here not because the problem is solved but because naming it is part of building with integrity.

The language translation feature — output in English or French based on user preference, with restaurant names never translated to protect Google Maps integration accuracy — is a small but deliberate decision about where AI translation helps users and where it would break things.

Outcomes

• Live and deployed at hungrytourists.vercel.app.
• Both the Instant Discovery and Trip Planning flows are functional end-to-end.
• Validated across multiple constraint scenarios: tight budgets (€80 for 4 people over 3 days), dietary constraints (Vegan + Chinese comfort cuisine, Halal), and multiple output languages.
• The stress test scenario — €80 for 4 people with Halal requirements — degrades gracefully to market stalls and street food rather than fabricating affordable restaurant data, which is the responsible AI behaviour the prompt was designed to produce.

What I Would Do Differently

I built the initial discovery feature without following a formal architecture process — no user flow diagram, no API contract document, no defined error states. The product works, but retrofitting the documentation revealed gaps in how OCR failures and empty result sets are communicated to users. On subsequent projects (including Parlez Bien, built immediately after) I established architecture documents before writing any code.

The Accra inclusion in the homepage city rotation is right in principle but currently underserved in practice — smaller cities with thinner grounding data produce lower-confidence results. The system prompt instructs the model to flag uncertainty in the trip narrative when grounding data is thin, but a more rigorous solution would involve city-specific confidence thresholds before the trip planning flow is offered.

What's Next

The food itinerary feature is the immediate focus — specifically the meal swap mechanic (AI regenerates a single meal slot with full trip context, so it doesn't repeat restaurants or exceed remaining budget) and the sharing feature (export a complete itinerary as a shareable link or PDF for travel companions).

The longer-term product question is monetisation: a freemium model where Instant Discovery is always free and Trip Planning requires a subscription would align the business model with the feature that delivers the most complex value.