A full-stack generative-AI application built in a four-hour hack-a-thon sprint — it turns "I want three days in Chicago on a budget" into a routed, budget-balanced, bookable itinerary, with RAG retrieval and a simulated checkout.
Try the live demo →TravelBuddy was our AIML-505 hack-a-thon final project: a five-person team, less than four hours, and one goal — take generative-AI concepts from the course past the notebook stage and ship a complete, usable application where an LLM does real planning work, retrieval grounds it in real data, and a non-technical person can use it without reading anything first.
We chose trip planning deliberately: it's a relatable domain that showcases RAG and multi-step AI orchestration, and it stresses exactly the things generative AI is bad at when used naively — staying inside a budget, respecting geography, and not inventing hotels that don't exist. Each of those failure modes forced a design decision you can see in the finished app.
Five of us — Abel Edea, Laykumar Lad, Sai Kaushik Surampudi, Suhail Syed, and Saurabh Rawat — built TravelBuddy in a hack-a-thon sprint of under four hours, using Claude extensively to accelerate architecture design and code generation while the team owned the scope, the module boundaries, and the evaluation of every AI-generated piece.
We brainstormed for a relatable domain that could showcase RAG and multi-step AI orchestration, converged on trip planning, and designed a concise API surface first — health, destination management, planning, and checkout — before writing feature code.
We scoped the system into clean modules — data, retrieval, planning, LLM integration, budget, and storage — with a frontend that mirrors the logical user journey screen by screen. Retrieval and planning were deliberately kept separate: retrieval selects real candidates from a curated knowledge base of hotels, restaurants, and activities; planning composes days from only those candidates.
With less than four hours on the clock, Claude accelerated architecture, code generation, and iteration on both backend and frontend. The discipline was staying inside the defined scope — backend and frontend sub-teams collaborated on payload contracts so AI-generated code on both sides actually fit together.
We tuned the domain knowledge base and validated the full flow under both deterministic (retrieval-only) and AI-enabled modes, with shared budget logic across backend and frontend so itineraries stay consistent and budget-aware either way. This was my role on the team — testing the end-to-end flows, catching where the two modes disagreed, and feeding issues back to the sub-teams.
We refined copy and UX to make the simulated nature of the data and checkout explicit — no real payments, no external booking systems. The frontend ships as a static React/Vite build, deployed here on GitHub Pages so anyone can use it.
We refused to let the LLM freewheel. Instead of "just ask the model for an itinerary," the architecture separates retrieval from planning: the model only composes from real, retrieved candidates, and shared deterministic budget logic constrains the result on both backend and frontend. That separation is why the app also works with no API key at all — and it's the difference between a demo that impresses and one that survives inspection.
The key move: the model never sees the whole world — only retrieved, real candidates, with the budget and structure stated as rules. Getting reliable structured JSON back took several prompt revisions.
The app labels every itinerary with its source, so viewers can see exactly which parts are AI and which are retrieval — an honesty choice I'd defend in any production AI product.
| Mode | When it runs | What it demonstrates |
|---|---|---|
| Composed by Claude | API key present, supported city | Full RAG pipeline — retrieval feeds the LLM, which composes the itinerary |
| AI-generated custom city | City outside the curated dataset | Generation without retrieval — clearly labeled so the trust boundary is visible |
| Built-in planner (fallback) | No API key | Pure retrieval + scoring — the demo works for everyone, always |
Generative AI becomes useful when you constrain it — retrieval for truth, rules for budgets, structure for output.
TravelBuddy is that idea, shipped.