Building an AI Trip Planner (With a Dog)
Challenge Accepted (Perhaps Foolishly)
I decided to challenge myself to build a full-stack MVP in a week. Why a week? Because I apparently hate sleep and love arbitrary deadlines. I'd been wanting to play with LLM APIs for a while, and after several questionable ideas were binned, I landed on a trip planning application.

The concept was simple: users log in, fill out a form, and an AI plans their perfect trip. But it needed something... else. Enter Wooster, my wife's childhood golden retriever, now reincarnated as an AI travel assistant. Because nothing says "trust my travel advice" quite like taking recommendations from a dog, right?

Tech Stack Decisions (Or: How I Learned to Stop Worrying and Love Express)
Time to pick the tech stack. Given the one-week timeline, this had to be quick:
- Backend: Express, because sometimes you just want things to work, and don't want to spend hours defining objects and interfaces
- Frontend: Considered Next.js, but when srting this project I'd never used it before, and learning a new framework on top of a week-long sprint to deliver an MVP is a bit like trying to learn Japanese the night before a holiday to Tokyo
- Database: Supabase, because:
- It's hosted (one less thing to break)
- Built-in auth
- Postgres under the hood (proper SQL, none of that NoSQL "is it a document? is it a database? who knows!" business)
- Has a GUI (but can still take SQL queries too)

The Features (Or: A List of Things I'll Probably Regret Promising)
Week One Must-Haves:
- Location querying (for when "somewhere hot" isn't specific enough)
- Trip planning form (the bread and butter)
- AI integration (the whole point, really)
- Basic itinerary display (no Comic Sans, promise)
Future Nice-to-Haves:
- Activity-based search (find me places to scuba dive!)
- Time machine (might be pushing it)
User Journeys (Or: A Dog's Guide to User Experience)
I mapped out the core user flows, trying to keep them as simple as a game of fetch:
Journey #1: The Quick Planner
User arrives → Logs in → Fills basic form (location + dates) → Gets AI itinerary → Saves for later
"Like when Wooster sees a tennis ball and just goes for it - direct, no complications."
Journey #2: The Picky Traveler
User arrives → Logs in → Fills detailed form (preferences, budget, pace) → Reviews AI suggestions → Tweaks activities → Saves final version
"More like Wooster inspecting his dinner bowl - needs everything just right."
Journey #3: The Return Visitor
Returns → Views saved trips → Copies previous trip → Modifies dates/location → Gets new AI suggestions
"The equivalent of Wooster returning to his favorite park - knows what he likes, but always up for variations."
Of course, what I actually built in week one was more like journey #1 - straight to the point, no fancy tricks. The rest would have to wait until Wooster learned some new commands.
What Could Possibly Go Wrong?
With planning as done as it was going to get given the week deadline, and optimism still inexplicably high, it was time to start building. Join me in part 2 where I discover exactly how many cups of coffee it takes to build an AI travel planner, and whether Wooster's digital reincarnation is more "helpful assistant" or "chaotic good".
Coming soon in Part 2: The inevitable "why isn't this working?" moments, the Stack Overflow deep dives, and the point where I seriously considered teaching my actual dog to code instead.