ABOUT
Trip Tailor is a chat-first travel planner. A single natural-language message becomes a streaming, day-by-day itinerary that the traveller can then drag, price, share and edit with friends in real time. Every place it recommends comes from a real catalogue with real prices, and the plan lands in an editable workspace rather than staying trapped in a chat thread. The product is feature complete on a Netherlands catalogue, with a second regional catalogue staged.
THE PROBLEM
Conventional travel search is keyword search wearing a trench coat. Someone who types “quiet canal town for a long weekend, not too touristy, under €120 a day” gets matched on “canal” and “weekend” and nothing else. Mood, budget ceiling, trip length and group size — every constraint that actually matters — are quietly discarded.
Handing that sentence to a language model instead solves the understanding problem and creates two worse ones. The model will happily recommend places that do not exist, or that the business has no way to price or book. And a conversation is a great way to get a plan and a terrible way to keep one: the traveller ends up scrolling back through chat history to find the itinerary they were given.
THE SOLUTION
We built Trip Tailor so that the model understands the request but the database supplies the answer.
Constraints become filters. A fast, inexpensive model reads the user’s sentence and extracts its hard constraints into structured database filters — “cheap 4- star places in spring” becomes a star rating of at least four, a budget price level, and a set of best-visit months. This is what makes semantic search obey hard limits, since pure similarity has no concept of “under €120.”
Meaning becomes a search. The sentence is turned into a vector, and three searches run in parallel across destinations, activities and hotels. Results are reranked against the user’s own travel profile, weighted so personalisation tilts the results without overwhelming relevance — a beach lover asking about museums should still get museums.
Grounded generation. A larger model writes a warm, streaming itinerary using only those retrieved results, and returns the machine-readable itinerary alongside the prose in the same response. Every place recommended exists in the catalogue, and the response carries back the database records that prove it.
Layers of validation over the model’s output. Any record identifier the model leaks into prose is stripped, a missing day count is computed rather than trusted, and date placeholders the model occasionally echoes verbatim are replaced with nulls. Each defence exists because the failure actually occurred.
A workspace, not a transcript. The same response populates four surfaces at once — the chat thread, a live map, a day-by-day itinerary panel and a source drawer. From there the plan becomes a real workspace: items drag between days, a budget tab prices the trip per person against group size, hotels can be searched for each leg, the itinerary exports to PDF, and the trip can be shared by email with view or edit permission, with every collaborator’s edit landing in real time.
Designed to degrade rather than fail. If filter extraction fails, search runs unconstrained. If one collection’s search fails, the others still return. If the stream drops, the client retries. External services are cached and rate-limited.
THE OUTCOMES
Trip Tailor turns one sentence into a grounded itinerary that arrives progressively rather than after a long blank wait, and lands somewhere the traveller can actually work with it. Every recommendation is a real entry from the catalogue rather than an invented one, and each answer shows the sources it was built from.
Two problems shaped the product more than any feature. A trip’s established facts — its length, travellers and stops — were being quietly overwritten when a user asked an unrelated follow-up, because the model re-decided them each turn. The fix was to promote those facts out of the conversation into structured state re-asserted every turn, and to have the client independently decide, from the turn’s classified intent, whether an itinerary is authoritative or merely illustrative. Separately, when two hotel data providers proved unusable — one requiring a paid commercial contract, the other having retired its self-service programme — the product was kept moving with a local provider built to the same interface, and swapping in a real one later is a single-file change, because the boundary had been drawn around the data shape the app needed rather than the vendor’s response format.
The project demonstrates our experience with retrieval-grounded AI, streaming interfaces and real-time collaboration — and, more usefully, with the engineering around a model that makes its output true, incremental and editable.
