Product Strategy
CityScout Build Thread / Part 1 of 4
Building CityScout: A Local-First AI Travel Companion
I'm building CityScout around a simple premise: travel should feel local and easy to make sense of. The product should help someone understand a city before it tries to optimise the trip for them.
Reading note
A clearer write-up of the product thinking, system choices, and tradeoffs behind the build.
In this post
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 apps — one for maps, one for bookings, one for reviews, one for notes, and a pile of browser tabs for saved places. It makes planning feel like admin, and it's harder to build any confidence when you're constantly switching contexts instead of forming a real 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 — helping someone understand what a city is actually good at, how its neighbourhoods differ, when to slow down, and where the local texture lives. The app should help the user travel with context, not pretend they already know the city.
Confidence in travel is rarely about how much information you have. It's about feeling oriented. If the product can help someone decide where to spend time, what to cluster together, and what to skip, it's already more useful than another 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 a strong baseline for maps, mobile interaction, local storage, and the kind of in-context use travel software depends on — which 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 bet is that careful AI beats omnipresent AI. CityScout doesn't need language generation everywhere — just where it actually reduces friction, stepping back when a stable city record or a plain interaction does the job better.