TripSlay

AI trip planner for editable day-by-day itineraries.

Comment

Inspiration

Travel planning often starts as scattered notes, map tabs, screenshots, and generic AI answers. TripSlay is built around the next step: turning a travel idea into an itinerary people can actually edit, inspect on a map, share, and reuse during the trip.

What it does

TripSlay helps travelers create structured day-by-day itineraries with places, timing context, map-based planning, sharing, and trip memories. The public demo shows the planning workflow, route/map experience, sharing, Travel DNA, and support surface without requiring judges to log into a personal account.

How it uses OpenAI

TripSlay was already an AI travel product before Build Week, and earlier versions were built with help from previous GPT models. The product's AI planning flow uses GPT through the OpenAI API for itinerary generation.

For OpenAI Build Week, I used Codex with GPT-5.6 Sol as a production refactoring partner. The work focused on making an existing AI product safer to ship: reading the codebase, refactoring key flows, fixing bugs found by tests and browser checks, and running a separate release-gate workflow before submission.

How I built it

TripSlay is built with Next.js, React, TypeScript, Tailwind CSS, Supabase/PostgreSQL, OpenAI API, Mapbox/MapLibre, Vercel, Sentry, and PostHog. The refactor evidence is in PR #231 on the private repository, with judging access already shared according to the Build Week rules.

Codex/GPT-5.6 Sol helped inspect the trip creation, guest draft, itinerary editor, sharing, memories, and AI planning flows. It also helped validate a real AI trip creation path locally and fix a regression where completed async jobs could miss Realtime updates by adding an authenticated polling fallback and correcting the job status API query.

Challenges

The main challenge was keeping the submission honest and release-safe. TripSlay is a real product, so I avoided risky last-minute deploys, avoided exposing personal account UI or real location data, and used Codex as a release gate instead of treating the hackathon as a one-shot code generation demo.

What I learned

Codex with GPT-5.6 Sol was most useful as a production engineering partner: it could follow existing code, preserve behavior, reason from failing tests or browser checks, and iterate on focused fixes. That made the Build Week work closer to a real release process than a simple prototype sprint.

Build Week evidence

Built With

Share this project:

Updates