Sortie: Building a travel planner where product, data and discovery compound
A planning-first travel product built around a simple idea: planning a good trip should feel less like managing twenty browser tabs and more like building something coherent.
The challenge
Travel products are very good at giving people things to search, save and book. The harder problem is what happens between inspiration and actually knowing what you are doing on Tuesday.
I started Sortie to work on that problem: a travel planning product capable of supporting real holidays, including multi-day and multi-city trips, discovery, bookings, hotels and detailed itineraries, while creating a data and search architecture that becomes more useful as the product grows.
That meant solving several problems at once: making complex itineraries simple to manipulate; supporting multi-segment trips without flattening them into one generic destination; understanding hotels, transport and other fixed anchors; making discovery useful during planning; avoiding repeated paid place lookups; and maintaining quality as the destination catalogue grows.
The product bet: planning first
The core product decision was to treat the itinerary as a living object.
A trip is not just a list of attractions. It contains fixed moments and flexible ones. A flight happens at a particular time. A hotel gives the traveller a geographic anchor. A restaurant booking cannot casually move three hours. A museum visit probably can.
That distinction affects almost every part of the product. Stops need to be added, removed and reordered. Days need to remain understandable as they become dense. Travel between cities needs to exist as part of the journey rather than disappearing between two destination pages. Bookings and documents need to relate to what the traveller is actually doing.
The goal is not to generate the maximum number of recommendations. It is to help someone build a trip they would actually want to take. That principle shapes how I think about product strategy and product design and the role of AI inside useful software: automation is valuable when it improves the decision. Generating more material is not the same thing.
The architectural decision that changed the product
The easiest architecture would be to ask Google for an answer whenever the interface needs one. It is also an architecture where every autocomplete, place lookup and discovery interaction can become another paid request.
Where possible, Sortie fetches place information once, stores it and reuses it. The database becomes the first source for future searches, while external providers become fallbacks for information Sortie does not already know.
That is partly an engineering decision, but it is also a growth marketing decision. Every place added to the system can improve what the product already knows. Destination coverage becomes reusable infrastructure. Search can become cheaper. Discovery has a stronger local dataset to work from. Public destination pages can draw from the same underlying entities instead of becoming a separate content project.
The useful asset is not the API request. It is the knowledge retained after the request.
Designing discovery to feed planning
Discovery inside a travel product is easy to make beautiful and surprisingly easy to make useless. A grid of landmarks can look excellent without answering the question the traveller actually has: would this work in my trip?
Sortie’s discovery system is designed around the handoff between finding something and doing something with it. A traveller should be able to explore a destination, understand a place, save it, and eventually move it into an itinerary without repeatedly starting from zero.
SEO as a product surface
Travel has enormous organic demand, but automatically generating thousands of thin destination and itinerary pages would be the fastest way to turn a useful product system into content landfill.
Public search surfaces therefore need a quality threshold. A generated itinerary should not automatically become an indexed itinerary. A destination should not receive a richer editorial surface simply because a route technically exists. Thin states can exist inside the product without pretending to be authoritative travel guides.
This creates a useful separation between coverage and publishable quality. The longer-term system is designed around destination coverage, structured place data, itinerary quality scoring and approval gates so organic growth can scale without requiring every city to be manually assembled one at a time. It is close to the logic behind entity SEO: useful entities and relationships should exist before the page is asked to rank.
Search is not bolted onto Sortie after the product is built. It influences what information is worth structuring in the first place, just as technical SEO influences what a site can reliably expose.
Building the system, not just the screens
Sortie is being built with Next.js and Supabase, with structured systems for trips, itinerary items, places, destination coverage, images, public itineraries and search data. The product and content layer follows the same product-led approach I use when thinking about SEO for SaaS startups.
But the more interesting work sits between the database and the interface.
A hotel is a database record, but it is also the geographic centre of a traveller’s morning. A destination is a route, but it is also a discovery surface. A place is a reusable entity, but it can also become a recommendation, an itinerary stop and part of an organic landing page. A booking is structured data, but the traveller experiences it as the thing I absolutely cannot miss at 4:30pm.
Getting those relationships right is the product. It should also make it easier to earn visibility in AI-generated answers, where clear entities, useful pages and evidence of relevance matter together.
Where the case study goes next
Sortie is still an active product build, so this case study deliberately starts before the neat ending. As the product moves towards launch, I’ll add measurable results around destination coverage and enrichment, the percentage of place and search requests served database-first, reduction in external API dependency, itinerary generation and quality-gate performance, indexed destination and itinerary coverage, organic discovery, signup and trip-creation conversion.
The useful question is not whether I can build another travel app. It is whether product architecture, UX, structured data and organic discovery can be designed together so that each new piece makes the entire system more valuable.
That is the experiment behind Sortie.