When I started Nomadist, the concept was straightforward: an online travel agency with a twist. Instead of searching by destination, users would search by vibe — historic getaways in ancient cities, a movie-inspired road trip, something fun for a family with young kids. The AI would interpret the feeling you were chasing and translate it into a real itinerary.
That concept made it to a working prototype. Then I pivoted. And the pivot turned out to be the more interesting story.
Nomadist is a live AI travel concierge. Built with React, Vite, Firebase, and the Duffel API. Developed by one person, without an engineering team, in roughly two and a half weeks of active development.
Visit the chatbot: Nomadist
Start with a Vibe
The traditional OTA model (search, filter, sort, book) is a solved problem. Kayak solved it. Google Flights solved it. Building another one would mean competing on price and distribution, neither of which I control.
The vibe-search model was an attempt to occupy different ground. Rather than asking where do you want to go, it asked what kind of trip do you want to have. The hypothesis was that most people don't start with a destination; they start with a feeling - and that a well-prompted LLM could bridge the gap between "I want something that feels like a spy thriller" and a set of real flights, hotels, and itinerary items.
I built the initial version with hotel search and an agent personality layer: a "charming" mode and a "snarky" mode, the latter deliberately irreverent about travel clichés. The personality layer was an early attempt to differentiate from the sterile UX of conventional booking tools.
The Pivot
The shift from OTA to chatbot was architectural as much as conceptual. The vibe-search interface was filtering and surfacing results. The chatbot model was holding a conversation, maintaining context, and acting on it: booking, saving, holding, and revising in real time. It was a more capable product.
The agent personalities carried over intact. What began as a brand differentiator in the hotel search model became the conversational voice of the chat interface: still charming, still snarky, now embedded in something that could actually execute.
The Domain
Here is what AI agents do not know, and what thirteen years in travel tech does: airline distribution is not uniform.
Some carriers allow seat selection and ancillary purchases (extra bags, priority boarding, in-flight meals) during the shopping flow, before payment. Others only surface those options post-purchase. That distinction is not a minor UX consideration. It determines whether a user can make a fully informed decision before committing, or whether they discover the seat is a middle row after they've already paid.
Seat map previews work the same way. Some airlines surface full interactive seat maps in the shopping API. Others don't. If your flow assumes they will, you get blank states and broken interactions for a significant portion of itineraries.
The AI does not know this. The Duffel API documentation does not narrate it. It has to be built with the understanding that these edge cases exist before you encounter them in production because the user experience depends on getting them right.
My solution was skip logic and a post-booking callback loop. For carriers that restrict ancillary purchasing to post-book, the flow acknowledges this at the shopping stage, sets an expectation, and gives the user a clear path back into the booking to complete those selections after payment. For seat maps, availability is checked at time of shop and the UI responds accordingly: showing a preview where one exists, gracefully degrading where it doesn't.
This is the kind of decision that looks invisible when it works. It only becomes visible when it doesn't.
Above: Restaurant research and flights shopping with a snarky agent.
Memory Trust
A conversational travel agent lives or dies on context. If a user spends twenty minutes narrowing down flights to Tokyo in mid-October, then asks "is there a good burger place around here?" — the agent needs to know what here means. The city. The neighborhood. The dates. The thread of the conversation.
Getting Gemini to maintain that state reliably across a session was one of the more stubborn problems in the build. LLMs do not inherently remember. Each prompt is, by default, a fresh start. Making the agent feel like it was listening (carrying forward the destination, the travel window, the preferences established earlier) required deliberately engineering the memory layer: structuring conversation history, extracting and persisting key trip parameters, and re-injecting that context with each new prompt so the model could reason against it.
The failure mode was subtle but corrosive. A user who had to re-state their destination every few messages would stop trusting the agent. Trust, in a booking flow, is everything. Nobody hands over a credit card to something that doesn't seem to be paying attention.
Above: Restaurant research and flights shopping with a snarky agent.
The Build
The tech stack was chosen for speed and verifiability: React and Vite on the front end, Firebase for auth and real-time Firestore sync, Node.js as an API proxy layer, and Duffel for all flight data including seat maps, ancillaries, holds, and live bookings.
The "Project Folder" became the product's source of truth: a persistent, cloud-synced container for saved flights, hotels, and places of interest. A flight found in search and saved to a project is re-validated against live pricing at checkout, so the price a user saves is not necessarily the price they'll be quoted if the market moves. That re-validation is surfaced clearly rather than silently - a decision that comes from knowing that price discrepancy is one of the most common complaint patterns in travel.
The 24-hour hold feature, powered by Duffel's hold API, lets users reserve a fare without immediate payment. The UI tracks this with an amber badge and a countdown timer. A confirmed purchase is green. A saved item not yet held or purchased is purple. The visual system communicates booking state at a glance.
The booking drawer itself is a five-step flow (passenger details, seat selection, extras, review, book) that automatically skips steps when the carrier's capabilities don't support them. That skip logic is the domain expertise made tangible in code.
Product Design
The AI agents handled the execution layer well. React component architecture, Firestore security rules, Zustand state management for the booking drawer, anonymous Firebase auth for pre-login exploration: all of it generated, debugged, and iterated on through natural language prompting. The development velocity was real.
What the AI contributed zero to was the product judgment underneath the execution. Which edge cases exist in airline distribution. Whether to show a degraded seat map or suppress it entirely. How to sequence a multi-step booking drawer so it doesn't create drop-off at the extras screen for carriers that won't surface extras until post-purchase. Whether the 24-hour hold is worth building at all given the additional state management complexity.
These are not engineering decisions. They are design decisions: the kind that come from years of mapping user flows, identifying where trust breaks down, and understanding that the moment a booking experience feels unpredictable is the moment a user leaves. That design intuition, combined with thirteen years of watching travel products succeed and fail in production, is what shaped every consequential choice in Nomadist. The AI executed. As a product designer, I decided what was worth executing.
The APIs
Duffel was the core flight engine used to search, real-time seat maps, ancillary extraction, 24-hour holds, and live bookings. It was the only API capable of handling the full booking lifecycle in a single integration, which was essential for keeping the backend manageable without a dedicated engineering team.
Nuitee (LiteAPI) powered hotel search and dynamic rate mapping. It provided the depth of inventory and room-level detail that a conversational agent needs to answer follow-up questions: not just "here are hotels" but "here is what's available in that neighborhood, in that room type, at that price point."
Google Gemini drove the intelligence layer parsing user intent from natural language, maintaining conversational memory across a session, and refining search results through dialogue. The stateful memory was particularly important: a user asking to "make it cheaper" or "find something closer to the center" needed the agent to hold the prior context rather than restart from scratch.
Google Maps handled geocoding and coordinate-based property matching translating neighborhood names and landmarks into the precise location data that hotel search APIs require, and surfacing the right properties when a user described a location conversationally rather than with an exact address.
The Result
Nomadist is live (in sandbox mode). It searches real flights to book and holds fares, saves itineraries, and handles the distribution quirks of actual airline APIs. One person built it. The engineering handoff was removed from the process entirely.
The more durable finding is about where the value sits. AI compressed weeks of implementation into days. What it could not compress was the experience required to know what to build.
That understanding predates the AI tools by a decade. The tools just made it possible to act on it directly.
Next Steps
The roadmap for Nomadist leverages the latest Gemini Live capabilities to move from text-only to a sensory experience:
Vision-to-Action: Uploading a photo of the Louvre to instantly trigger a "Save to Project" ticket booking flow.
Voice-First Interaction: Low-latency, human-like dialogue via Gemini Live API for hands-free trip planning.
Document Intelligence: Automatically extracting flight numbers and dates from confirmation PDFs to populate the user's data grid.
