Inspiration
What it does
Tripaholic puts the whole trip in one hub. Tell the booking agent what matters ("cheapest direct flight from JFK, arriving before noon") and watch it work live: Gemini function calling drives search and booking tools, compares the options, explains its pick with real numbers, and books it, or waits for your one-click confirmation. Don't like the pick? Ask for another option and the agent proposes the next best.
A Gemini structured-output planner then fills a Google Calendar-style itinerary with a day-by-day plan. It's built around your flights and hotel, keeps to one city or routes across a state or country depending on the scope you chose, and explains every choice with a "Why this plan" summary and a reason on every event. Drag, resize, delete, add your own plans, and regenerate: your changes stay. Export the itinerary as an .ics file for Google, Apple, or Outlook Calendar.
How we built it
- Next.js (App Router) + TypeScript + Tailwind, with FullCalendar for the itinerary and zod validation on every API route.
- Google Gemini (
@google/genai), used four ways: a structured-output itinerary planner (JSON schema + zod, one corrective retry, then deterministic post-processing for trip range, flight windows, daily hours, no overlaps, and pacing); a function-calling booking agent (search/book tool loop, every thought, call, and result streamed to the UI over SSE and saved); reasoned explanations on every event and booking; and optional search grounding. - MongoDB Atlas for all app data (trips, events, itinerary summaries, bookings, and the agent's step log).
- Vultr Cloud Compute VM running the Next.js standalone server under systemd behind Caddy (automatic HTTPS), on a GoDaddy Registry domain.
- Cursor was used to create the initial static prototype of the design. Claude Code implemented the app from a written phase-by-phase plan, pushing one branch per phase. Grok Bot reviewed each pull request, and Claude Code addressed every review with follow-up commits before a human merged to main.
Challenges we ran into
- Time zones everywhere: events are stored in the destination's wall-clock time, flights are converted from origin to destination time, and the .ics export generates a DST-correct VTIMEZONE so Outlook reads it properly.
- Making regenerate safe: events you move or edit are pinned and survive, and a new plan is written before the old one is removed.
- Keeping the demo from dead-ending: typed Gemini errors with bounded retries, plus a deterministic offline planner and agent that take over (and say so in the UI) when Gemini is unavailable.
- "Show me another option" had to exclude the rejected option by a stable identity, so a re-search with different dates or party size can't bring it back.
Accomplishments that we're proud of
What we learned
What's next for Tripaholic
- Plug in real flight and lodging providers behind the existing provider interfaces (flights and stays are currently realistic demo data, clearly labeled).
- User accounts and authentication (the hackathon build has one demo user).
