Trip Plan AI

What it is

The organizer describes the trip in a sentence, invites the group, and gets a day-by-day itinerary everyone can see, vote on, and adjust. Friends add their availability and suggestions, the planner drafts and revises the plan, and the trip carries its own map, weather, packing list, checklist, budget, and a bill splitter that tracks who actually paid what. Nothing the AI writes lands on the trip until the organizer accepts it.

What I built

I started it from a written spec, wrote the large majority of the code, and took it to production in a little over two weeks.

• Intake that shows its work. One sentence becomes a trip brief. Every field the model filled is marked as AI-read, and anything it had to guess, like dates from "in November", is flagged for a person to check. Organizers who have already booked can upload a flight or hotel screenshot instead; the extraction schema has no field for a booking reference or card number, the file is read once and never stored, and "I couldn't read that" is a valid answer rather than a guess.
• A planner that researches, asks, then proposes. Before drafting, it searches Google Places for the destination and asks the organizer which places matter. Instead of holding a process open while it waits, the run ends and the next one replays the answer, which is cheaper than a workflow engine and safe because the planner can only propose. It drafts day by day, saves each finished day so a timeout doesn't lose paid work, and checks the result against the schema, overlapping times, the budget, and anything locked.
• Proposals, not edits. Every AI change arrives as a proposal with a preview of what's added, changed, or removed. Members vote, organizers accept or reject, and accepted plans are versioned, so restoring an old version adds a new one instead of rewriting history. Stale edits get a conflict instead of overwriting someone else's work, and locked stops are protected from the planner in shared code the server enforces.
• No fabricated certainty. Every activity is labeled exact, estimated, AI-inferred, or missing. Weather uses real forecasts when the trip is close and clearly labeled seasonal averages when it isn't, and missing place data is shown as missing.
• Money that stays fair. Costs name the people they cover, so a late joiner doesn't pay for a day they missed, and a removed member's share is flagged rather than quietly spread across everyone else. Settlements net to zero.
• Cost on the record. Every model call is priced against its trip, including the thinking tokens that make up most of a run's cost, and how hard the main model thinks is a setting.
• Ops for a small team. One Docker image on Railway serves the API, the SPA, and a server-rendered travel blog with generated cover images. A deploy runbook records the silent failures we hit, the rate limiter keys on the real client address behind the edge, and 300+ tests plus a smoke script that walks the go/no-go list keep it honest.

Where it started

It began as a one-off website I built for a friends' trip to Manila, with the daily route, who was free when, and what everyone could spend. Trip Plan AI is the reusable version, so any group can get that board without someone building it by hand.