--- title: "Chat-First, Not Chat-Also: Building an AI-Native Travel App" description: There is a spectrum from AI feature to AI product. Most travel apps bolt on a chatbot. We built the entire product around the conversation. canonical: https://nowah.xyz/blog/chat-first-not-chat-also lastModified: "2026-08-07T07:54:40.580Z" --- # Chat-First, Not Chat-Also: Building an AI-Native Travel App There is a spectrum from AI feature to AI product. Most travel apps bolt on a chatbot. We built the entire product around the conversation. In 2023, Expedia launched a ChatGPT-powered trip planning feature. You could open a chat window inside the Expedia app, ask it about destinations, get some suggestions. It was fine. And then when you wanted to actually book something, you got dumped back into the same search form, the same results grid, the same checkout flow that Expedia has had since the early 2000s. The chat was a feature. The product was still a search engine. Booking.com did something similar. Their AI trip planner could help you brainstorm destinations and organize ideas. But the actual booking? Same filters, same listings, same old interface. This is the pattern across the industry. Every major travel company added AI in 2023 and 2024. Almost none of them changed their product because of it. The AI lives in a sidebar, a separate tab, a "try our new AI assistant" banner. The real product, the thing that actually processes searches and takes your money, remains untouched. We built Nowah the other way. The conversation is the product. There is no search form behind the chat. There is no results grid underneath. The AI agent is not an add-on. It is the entire experience. And that distinction, between chat-first and chat-also, determines almost everything about how the product works. ## The AI product spectrum ![Illustration for this section](https://pics.nowah.xyz/website-media/product-004-img-1.webp) It helps to think about this as a spectrum rather than a binary. On one end, you have products with no AI at all. A traditional OTA from 2015 with a search form, filters, and a booking page. Simple, functional, and exactly the same for every user. Next comes the AI feature. This is where most travel companies sit today. Their core product is unchanged, but they have added an AI chatbot somewhere. Maybe it helps with customer service. Maybe it can suggest destinations. But if you removed the AI entirely, the product would still work. It would still search flights, display results, process bookings. The AI is decorative. Then there is AI-augmented. The product uses AI to improve existing flows. Smart sorting that considers your browsing history. Personalized recommendations in the results. Price prediction that tells you whether to buy now or wait. The AI makes the existing product better, but the product's fundamental interaction model, search form to results list to booking page, is the same. At the far end is AI-native. The product was designed from the ground up around AI capabilities. The interaction model assumes AI. The [information architecture](/blog/five-tabs-ai-first-information-architecture) assumes AI. The booking flow assumes AI. Remove the AI and the product does not just get worse. It ceases to function at all. There is no fallback search form because one was never built. Nowah sits at the AI-native end. When you open the app, you land in a conversation. That conversation is where you search, compare, decide, and book. The AI agent is not layered on top of a traditional OTA. The traditional OTA was never built. There is nothing underneath. About 65% of consumers under 35 are comfortable booking travel through an AI agent. That number is growing fast. We are building for where the market is heading, not where it was. ## Architecture decisions that only work when AI is the foundation When you commit to chat-first, you end up making engineering and [design decisions](/blog/year-in-review-design-decisions-shipped) that would be nonsensical in a traditional OTA. We do not have a search results page. In a traditional travel app, the results page is the most important screen. Teams spend months optimizing it. They A/B test card layouts, sort orders, filter placements, pagination strategies. We have none of that. Search results appear as cards inside the conversation. The AI picks three options and presents them with context about why each one was selected. There is no page to optimize because there is no page. We do not have a filter sidebar. Filters exist because the product cannot figure out what the user wants, so it gives the user tools to narrow things down themselves. In a conversation, the user just says what they want. "Only direct flights" is a sentence, not a toggle. "Under $500" is a phrase, not a slider. "No red-eyes" is a preference, not a checkbox. The AI applies these as constraints automatically. We do not have a separate checkout flow. In a traditional OTA, you select a flight, get redirected to a booking page, enter traveler details, review the itinerary, and then process payment. That is four or five page transitions, each one a drop-off point. In Nowah, the booking happens inside the chat. You pick an option, confirm the details, and pay. Same thread, same context, no navigation. These decisions only make sense if the AI is good enough to handle the full flow. If the AI stumbles, there is no fallback. That is the trade-off of being AI-native. You are betting your product on the AI's quality. We made that bet deliberately, and we invest accordingly in making the agent better every day. [Streaming responses](/blog/streaming-ai-responses-real-time-chat) are another AI-native decision. When the agent searches for flights, you see it working in real time. "Searching flights from SFO to Tokyo..." "Found 247 options, analyzing..." "Here are the three best options for your dates." This streaming approach increases engagement time by two to three times compared to a spinner-and-wait experience. But it only works if the agent's thinking process is worth watching. In a bolt-on chatbot scenario, the thinking is just "querying the same database the search page uses." In an AI-native product, the thinking is genuine analysis that the user benefits from seeing. ## What you lose bolting AI onto legacy architecture ![Supporting diagram](https://pics.nowah.xyz/website-media/product-004-img-2.webp) When Expedia added their ChatGPT feature, they faced a constraint we did not have: the chat had to work with the existing product. It could suggest destinations but had to link back to the Expedia search page for actual results. It could discuss hotels but could not display an interactive hotel card with a "book now" button inside the chat. The existing architecture was not designed for conversation-native commerce. This is the fundamental problem with chat-also. The AI operates within the boundaries of the existing system. It can talk about things, but it cannot do things. It can recommend a flight, but it cannot show you a booking card with real prices and a one-tap payment option. That requires rebuilding the booking flow from scratch, which requires rebuilding the data layer, which basically requires rebuilding everything. Most companies are not willing to do that. And honestly, it makes sense for them not to. Expedia processes billions of dollars in bookings through their current system. Rebuilding it around AI is a multi-year, high-risk project with no guarantee of success. The chatbot sidebar is the safe move. It checks the "we have AI" box without risking the revenue engine. The result is that the chatbot becomes a toy. Users try it once, realize it cannot actually complete a booking end-to-end in the conversation, and go back to the search form. The chat icon sits in the corner, unused. Meanwhile the company reports "AI-powered features" in their quarterly earnings and everyone moves on. We see this with users who switch to Nowah from [traditional OTAs](/blog/ai-travel-booking-vs-traditional-otas). Their first instinct is to look for the search form. When they do not find one, there is a brief moment of confusion. And then they type something like "flights to London next week" and the agent responds with real options, and within two exchanges they have flight cards with real prices in front of them. The confusion turns into relief. They did not have to fill anything out. They just said what they wanted. Users who interact with AI assistants during booking show 20-30% higher average order values compared to traditional search flows. Part of that comes from the AI recommending relevant add-ons at the right moment. But mostly it is because users who feel well-served by the agent make more confident decisions and feel comfortable with the purchase. ## The chat-first information architecture Building chat-first does not just change the main screen. It changes the entire information architecture of the app. In a traditional travel app, the navigation is organized around content types. There is a flights page, a hotels page, maybe a car rentals page. There is a search section and a "my trips" section and a profile section. The user navigates between these by tapping tabs and following links. The mental model is "I am in the flights section now" or "I am in the hotels section now." In Nowah, the mental model is "I am in a conversation." The conversation can be about flights, hotels, both, or neither. You do not navigate to a flights section to search for flights. You say "find me a flight" and the agent handles it. You do not navigate to a hotels section after that. You say "now I need a hotel" and the conversation continues with the full context of your flight booking already established. The agent knows when you arrive, what neighborhood you might want to stay in based on your preferences, what your remaining budget looks like. This means the five tabs in our app serve fundamentally different purposes than tabs in a traditional OTA. Our center tab is Chat, the primary interaction surface. The Trips tab is a post-booking command center where you manage active and past trips. The Tools tab has utilities like [currency conversion](/blog/launching-currency-conversion-global-travelers) and tip calculators, things you use during a trip. The Passport tab is a travel journal. The Profile tab feeds your preferences into the AI memory system. None of these tabs contain search forms. None of them are organized around inventory categories. Every tab either feeds into the AI agent or benefits from it. The conversation is the center of gravity, and everything else orbits around it. This architecture means transitions between different types of travel planning are seamless in a way they cannot be in a traditional app. On Expedia, booking a flight and then booking a hotel are two separate workflows. You finish one, navigate to the other, and start a new search with a new form. On Nowah, it is a natural continuation of the same conversation. "Great, the flight to Rome is booked. Now let's find a hotel. Based on your flight arrival at 2 PM and your preference for walkable neighborhoods, I'd suggest staying near Trastevere or the Spanish Steps area. Want me to search both?" That transition, from flight booking to hotel search with full context carried over, is something a chat-first architecture enables naturally. In a chat-also architecture, it is nearly impossible because the hotel search system has no awareness of the flight booking system. ## Constraints that create better products People ask us what we deliberately did not build. The list is long, and each omission was a fight. We did not build a browse destinations feature. Traditional travel apps have an Explore section where you can scroll through deals, trending destinations, and inspirational content. We skipped that. If you want destination inspiration, ask the agent. "Where should I go in June? I like beaches and good food, and I've already been to Thailand and Mexico." That is a better starting point than scrolling through a grid of generic destination cards, because the agent knows you and the grid does not. We did not build price alerts as a standalone feature. In a traditional OTA, you set a price alert because you are not ready to buy and you want to be notified when the price drops. In a conversational model, you tell the agent "I want to fly to Rome in March but only if I can find something under $600." The agent monitors prices and comes back to you when it finds a match. Same outcome, better experience, because the agent also remembers your other preferences and will not alert you about a flight with a 7-hour layover just because it is cheap. We did not build comparison tables. Expedia lets you compare flights side by side in a table view. We do not need that because the agent explains the differences in natural language. "Option A is $150 cheaper but has a 2-hour layover in Frankfurt. Option B is direct but arrives later. Option C is the best balance of price and timing." That is more useful than a table because it surfaces the trade-offs in human terms rather than making you mentally process raw data. Each of these decisions was an argument internally. Someone always makes the case for building the traditional feature "just in case." The concern is always the same: what about users who expect that feature? What about people who want to browse? What about power users? But every traditional feature you add dilutes the conversation-first model. If users can browse destinations in a grid, some of them will do that instead of asking the agent. And those users will have a worse experience because the grid knows nothing about them while the agent knows everything. Saying no to traditional features is how you keep an AI-native product AI-native. ## How Expedia's chatbot proves the point Expedia is the perfect case study in chat-also versus chat-first. They were one of the first major OTAs to add an AI chat feature, and they are one of the most technically sophisticated travel companies in the world. If anyone could make the bolt-on approach work, it would be Expedia. And yet. The Expedia chatbot can answer questions about destinations. It can help brainstorm trip ideas. It can provide some price context. But when you want to actually see flights with real prices, the chat sends you to the Expedia search results page. When you want to book, you go through the standard Expedia checkout. The chat is a concierge that walks you to the front desk and says "they'll help you from here." The [OTA conversion](/blog/booking-conversion-rates-ai-agents) rate stays stuck in the low single digits because the actual booking flow, the part where money changes hands, has not changed. The AI made the top of the funnel friendlier but did not fix the middle and bottom where most of the drop-off happens. This is what happens when AI is a feature added to an existing product rather than the foundation of a new one. The AI can only go as far as the existing architecture allows. And the existing architecture was designed for forms and pages, not conversations. To their credit, Expedia is aware of this gap. They have been investing heavily in their AI capabilities. But retrofitting a twenty-five-year-old product to be conversation-native is like converting a cargo ship into a speedboat while it is still carrying cargo. You can make improvements, but the fundamental shape constrains what is possible. ## Building for the AI-native generation There is a generation of users, roughly 35 and under, who grew up with voice assistants, chat interfaces, and AI tools. For them, typing into a search form and scrolling through results feels old-fashioned. Not in a retro-cool way. In a "why do I have to do all this work" way. These users text more than they call. They send voice notes instead of writing emails. They ask AI assistants questions every day. The conversational interaction model is default for them. The search form is the unfamiliar interface. When we test Nowah with users in this demographic, the onboarding is almost instant. They open the app, see the chat, and start talking. There is no learning curve because they have been using chat interfaces their entire lives. The product meets them where they already are. For users less familiar with AI, the onboarding takes a bit longer. Some type very structured queries like "flights SFO to LHR March 15-22" because that is what they are used to from search forms. The agent handles those just fine and responds naturally. Over time, these users start typing more conversationally. "Can I get something a bit cheaper?" "What if I leave a day later?" "Actually, what about hotels too?" They discover that the conversation can do things a form never could. The AI-in-travel market is projected to reach $1.2 billion by 2028, and that estimate might be conservative given how quickly capabilities are improving. Products built around AI today will own the next decade. Not because AI is trendy, but because the interaction model is genuinely better for complex, high-consideration purchases like travel. The form-based model has had twenty-five years of optimization and it still converts in the low single digits. That is the ceiling. The conversational model is just getting started. We built Nowah as a chat-first product because we believe the conversation is a better way to book travel. Not a better add-on. Not a better sidebar feature. A better product. The distinction between chat-first and chat-also is not semantic. It is architectural, strategic, and ultimately it determines whether AI actually transforms the user experience or just puts a friendly face on the same old system. --- Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. [Plan your next trip](https://app.nowah.xyz).