Travel Partner

Trip planning often starts before a user is ready to create an account. The product needed to support messy early planning, rough budgets, saved places, and itinerary edits without forcing cloud persistence too early or making AI output feel like a final answer.

The MVP had to stay useful with no auth session, avoid exposing AI provider credentials to the browser, and keep future cloud sync possible without changing the planning model later.

• Anonymous users should be able to draft a trip locally
• Provider keys and generation prompts belong in server-side code
• Cloud writes are unsafe until user ownership is enforced
• Collaboration, public sharing, booking, and payments stay out of MVP

The planning model separates trip profile, days, itinerary items, expenses, and saved places. That keeps the UI useful in local mode while leaving a clean path to authenticated persistence once auth and ownership policies are ready.

• Trip profile captures dates, base area, traveler style, and budget comfort
• Generated itinerary items remain editable instead of becoming locked AI output
• Budget and saved-place panels sit next to the timeline so planning tradeoffs are visible
• The public demo uses fake places and simulated generation only

The public portfolio intentionally shows a safe representative slice of the real app. It demonstrates the product shape without exposing private trip details or pretending every production-only surface belongs in a public demo.

Local-first is the product default until the trust boundary is complete. If Supabase browser config is absent, or if a user session is missing, the app stores trip drafts locally. Authenticated cloud storage becomes the production path only after user-owned rows can be enforced.

• local_missing_env stores drafts in localStorage
• local_unauthenticated also stays local, even if browser-safe Supabase config exists
• supabase_authenticated is the only production cloud storage mode
• Trip child rows inherit access through the parent trip owner

AI generation is treated as an assistant, not the product's source of truth. The browser sends structured constraints to a server route; the server calls the provider and returns a draft plan that the user can edit, reject, or save locally.

• Provider credentials never use public browser env names
• Generated plans are labeled as drafts and remain editable
• The app can degrade to manual planning if generation is unavailable
• No itinerary export, share link, or booking flow is included in the MVP

The Travel Partner story shows product judgment and security judgment at the same time. The app starts with a low-friction planning loop, but it does not pretend auth, RLS, cloud sync, collaboration, or bookings are solved before they actually are.