Go.

Inspiration Go. was inspired by a simple frustration we all shared while travelling: even when time is limited, planning a day often explodes into dozens of tabs, options, and decisions. We noticed that the hardest part of travel planning isn’t lack of information, but decision fatigue — the mental cost of choosing between too many “good enough” options. We wanted to explore what would happen if a system did the opposite of most travel apps and deliberately removed choice instead of adding more. What We Learned Working on Go. taught us that simplicity on the surface often requires more rigour underneath. Producing a single, confident plan is much harder than generating a list of recommendations, because the system has to reason about real constraints like dates, time windows, and sequencing. We also learned that users are surprisingly comfortable delegating decisions if the system is decisive and consistent, even without personalisation or accounts. How We Built It We built Go. as a minimal full-stack web application with an intentionally sparse interface: the user enters a city, their available dates and time windows, and a high-level “vibe”, then presses GO. Under the hood, the problem was treated as a constrained scheduling task rather than a content-generation problem. The system mapped available time windows to a small set of candidate activities and produced a single ordered timeline that fit within those constraints, refusing to overfill the schedule. We used Claude for structured reasoning and generation of concise itinerary steps, but kept all decision logic deterministic and bounded to ensure predictable outputs. The frontend was designed to surface only the next action, reinforcing the idea that the plan is meant to be followed, not endlessly tweaked. Challenges One of the main challenges was resisting feature creep. Many obvious extensions — alternatives, maps, filters, and personalisation — directly conflicted with the core idea of decisiveness. Another challenge was handling time realistically: even without external APIs, the system needed to respect dates and windows in a way that didn’t silently produce impossible plans. Finally, we had to balance trust and simplicity: the system had to feel confident enough that users would follow it, without pretending to be omniscient.

Built With

• claude
• google-places
• openweathermap