Building a Python Itinerary Generator with AI and Location Scraping (Cursor + Gemini 2.5 Flash)
What happens when you take an itinerary feature built for an Airbnb-style website and turn it into its own standalone tool? That's the challenge in this build: a self-contained Python itinerary planner that dynamically pulls real location data instead of leaning on pre-scraped content. Here's how it came together, what broke along the way, and where this tool could go next.
What This Tool Does
This is a Python-based itinerary planning app that generates trip plans based on real user input: dates, number of adults, kids, and dogs, budget preferences, and custom activity requests. It also exports finished itineraries to PDF, making it something you could actually hand off to a client or use for your own trip planning.
Instead of relying on a fixed database of pre-scraped locations, the goal was to make the tool pull location-based ideas on the fly, using free sources like OpenStreetMap, Wikipedia, and DuckDuckGo to find real businesses, restaurants, and activities wherever the user points it.
Why This Matters
A lot of AI travel tools lean on static datasets or expensive APIs. This build was about testing the other end of the spectrum: can a scrappy, free-data approach hold up well enough to generate a usable itinerary for a real location? That question shapes a lot of the decisions in this session, from tool architecture to which APIs make sense long-term.
It's also a good case study in "vibe coding" with Cursor and an LLM (Google Gemini 2.5 Flash in this case) — defining features conversationally, testing live, and debugging in real time instead of planning every detail up front.
How the Build Works
The process started by pulling reference material from the original Airbnb-style website's itinerary feature and feeding it into Cursor as an example. From there, the core feature set got defined: date selection, party composition (adults, kids, dogs), budget level, custom activity requests, and PDF export.
With the core scaffolding in place, the tool was tested live against a few different locations:
- Colorado Springs, as the first real test case
- Portland, Oregon
- Portland, Maine — specifically to see how the tool handles ambiguous or duplicate place names
Along the way, there's a real debugging session around a broken location scrape, plus a practical comparison of free scraping methods versus paid options like the Google Places API. Cost also came up directly — comparing Gemini Flash against Claude for this kind of workload, since API pricing matters a lot once a tool like this scales past a personal project.
Where This Could Go Next
The session closes out with ideas for leveling this tool up further, including:
- Weather API integration for smarter day-by-day planning
- GPS-based distance filtering to keep suggestions realistic
- Event APIs to surface concerts and local happenings
- Database caching for previously scraped areas, which would set the stage for turning this into a full web application
Key Takeaways
- Free scraping sources (OpenStreetMap, Wikipedia, DuckDuckGo) can produce usable results, but with real tradeoffs against paid APIs
- Defining features conversationally with an LLM inside Cursor speeds up prototyping significantly
- Testing against multiple, even ambiguous, locations early exposes weaknesses before they become bigger problems
- A tool like this has a clear path from standalone script to full web app with caching and additional API integrations
Got a tool idea you want to see built next? Drop a comment and let me know what you'd like tackled. Follow along for more builds like this one, where the process, the debugging, and the decisions get shown in full, not just the finished product.