Product Strategy
CityScout Build Thread / Part 1 of 3
Building CityScout: A Local-First AI Travel Companion
I am building CityScout around a simple premise: travel should feel local, legible, and calm. The product is meant to help someone understand a city before it tries to optimise the trip for them.
Contents
The product should help you orient yourself before it tries to be clever.
Why The Problem Matters
Most travel planning still happens across too many surfaces. One app for maps, one for bookings, one for reviews, one for notes, and a handful of tabs for saved places. That fragmentation makes planning feel like administration. It also makes it harder to build confidence, because the user keeps switching between contexts instead of forming a coherent picture of the trip.
CityScout is meant to do the opposite. The product should bring discovery, planning, and trip-time reference into the same mental model so the experience feels like one flow rather than a pile of disconnected decisions.
Why City-First Matters
A city-first product starts with the place, not the booking. That means helping someone understand what a city is good at, how its neighbourhoods differ, when to move slowly, and where the local texture actually lives. The app should feel like it is helping the user travel with context, not pretending they already know the city.
That distinction matters because confidence in travel is rarely about raw information volume. It is about feeling oriented. If the product can help a person decide where to spend time, what to cluster together, and what to ignore, it becomes more useful than a list of generic suggestions.
Why I Chose iOS First
CityScout is a native iOS app built with SwiftUI and SwiftData because the product belongs close to the trip. A travel companion needs to live on the device, feel fast, and stay useful when the user is moving between places, not sitting in a desktop workflow.
The platform choice is also a product decision. iOS gives the app a strong baseline for maps, mobile interaction, local storage, and the kind of in-context use that travel software depends on. That makes the first version easier to trust and easier to keep simple.
Why AI Should Stay Selective
- Use AI to start itineraries and answer guide questions, not to replace the whole product.
- Keep structured city content and saved trip data as the source of truth.
- Prefer clear outputs that can be reviewed, stored, and reused.
- Let AI improve orientation and drafting, not obscure the underlying travel model.
The product bet is that careful AI is more useful than omnipresent AI. CityScout does not need to use language generation everywhere. It needs to use it where it reduces friction, then step back when a stable city record or a simple interaction is the better answer.