---
title: "Why We Built Nowah: The AI Travel Platform the Industry Needed"
description: "Industry studies have long reported that travelers bounce across many sites before booking a single trip. We thought that was absurd. Here's why we built an AI-native travel platform from scratch instead of bolting a chatbot onto the old model."
canonical: https://nowah.xyz/blog/why-we-built-ai-travel-platform
lastModified: "2026-08-07T07:58:07.480Z"
---

# Why We Built Nowah: The AI Travel Platform the Industry Needed

Industry studies have long reported that travelers bounce across many sites before booking a single trip. We thought that was absurd. Here's why we built an AI-native travel platform from scratch instead of bolting a chatbot onto the old model.

Somewhere around the 34th browser tab, you stop caring about finding the best flight and start caring about finding any flight. You've been at this for two hours. You've compared prices on [Google Flights](/blog/best-flight-booking-2026-ai-vs-google), cross-referenced with Kayak, checked Expedia for bundles, looked at the airline direct, read three Reddit threads about whether that layover in Dallas is long enough, and now you're staring at a hotel listing on Booking.com wondering if "city view" means you can actually see the city or just the parking garage next door.

This is how most people book travel in 2026. It hasn't gotten meaningfully better in fifteen years.

We built Nowah because we were tired of it. And because we believed the technology finally existed to do something fundamentally different.

## The 38-site problem

![Illustration for this section](https://pics.nowah.xyz/website-media/product-001-img-1.webp)

Google and Phocuswright published research showing the average traveler visits a large number of sites before making a booking. Thirty-eight. That number has been cited so often it almost loses its punch, but sit with it for a second. No other consumer purchase works like this. You don't visit many websites to order dinner. You don't comparison-shop across 38 retailers for a pair of shoes. But for some reason, we've accepted that spending $2,000 on a vacation requires a multi-week research project spread across dozens of platforms.

The journey gets worse the closer you look. Those 38 sites translate to roughly 45 or more touchpoints over two to three months. You search, you save, you forget what you saved, you search again. You text your travel partner a screenshot from one site, they send back a link from another. You lose track of which dates had the better price. Eventually, exhaustion wins and you book something that feels "good enough."

This pattern has real consequences. About 70% of travelers report feeling overwhelmed by options during the booking process. And OTA [conversion rates](/blog/low-conversion-rates-ai-fix) have been stuck in the low single digits for over a decade. Think about that from the other side: the companies spending billions on travel search have failed to convert 95% or more of the people who show up looking to buy something. That's not a minor UX issue. That's a structural failure.

## What legacy OTAs optimized for (and what they missed)

To understand why travel booking is still this bad, you have to understand what the OTAs were actually trying to solve when they were built.

Expedia launched in 1996. Booking.com followed in 1997. The internet was young, and the problem they tackled was real: getting airline and hotel inventory online so consumers could see it without calling a travel agent or visiting a storefront. That was genuinely transformative. Suddenly you could compare flights from your living room at midnight.

But the core UX paradigm they established has barely changed since. You fill out a search form. Origin. Destination. Dates. Number of travelers. Hit search. Get a list of results. Sort. Filter. Click. Compare. Go back. Search again.

The entire product philosophy centers on inventory display. Show people as many options as possible, let them filter and sort, and hope they find something they want. This made sense when the hard problem was access to inventory. It makes much less sense now that everyone has access to roughly the same inventory and the hard problem is actually choosing.

Kayak tried to solve the comparison problem by aggregating across OTAs, but it just added another layer of links and redirects. Hopper tried to solve the timing problem by predicting price movements, which is useful but narrow. Google Flights brought the power of Google's infrastructure to search speed and price tracking, but it's still fundamentally a search box that returns a list.

None of them solved the actual user problem: I want to go on a trip, and I want someone who knows what they're doing to help me figure out the details.

That used to be what travel agents did. And the industry killed them off without building a replacement for the part of their job that actually mattered.

## Adding AI vs. building around AI

![Supporting diagram](https://pics.nowah.xyz/website-media/product-001-img-2.webp)

When ChatGPT hit in late 2022, every travel company scrambled to add AI to their product. Expedia launched a ChatGPT plugin. Booking.com built an AI trip planner. Kayak added a chat feature. Google started generating AI summaries for travel queries.

Here's what most of them did: they took their existing product, which is a search form connected to a results list connected to a booking flow, and they bolted a chatbot onto the side of it. The chatbot could answer some questions about destinations and maybe suggest a few options, but when you actually wanted to book, you got dumped back into the same old interface.

This is the difference between adding AI to a product and building a product around AI.

When you add AI as a feature, it's a layer on top of your existing architecture. The AI can only do what your existing system supports, and the interaction model still follows the old paradigm. The chat window is a sidebar. The real product is still the search form and the results grid.

When you build around AI, the conversation is the product. There's no search form to fill out. There's no results page to scroll through. You tell the AI what you want, and it handles the rest. The entire architecture, from the data layer to the interface to the booking flow, is designed for this interaction model.

We chose the second approach. Not because it's easier (it is absolutely, definitively not easier), but because we believe it's where the industry has to end up, and getting there requires starting from scratch rather than retrofitting.

## Why now: the convergence moment

People have been talking about AI travel assistants for years. IBM tried it with Watson. Various startups attempted it with earlier generations of NLP. None of them worked well enough to matter. So why did we think 2024 was the right time to start building?

Three things converged.

First, large language models got good enough to handle the ambiguity of real travel conversations. When someone says "I want to go [somewhere warm](/blog/ai-handles-somewhere-warm-cheap) in March, maybe Southeast Asia, but not too touristy, and I need to be back by the 15th for my kid's birthday," an LLM can parse that into actionable constraints. Earlier NLP couldn't. It would choke on "not too touristy" because that's a subjective, context-dependent preference, not a structured data field.

Second, real-time travel data APIs matured to the point where an AI agent can actually search live inventory, check real prices, and initiate real bookings. The data plumbing got good enough to support the interaction model we wanted. Five years ago, getting reliable real-time pricing from airlines and hotels through APIs was a mess of inconsistent formats, stale data, and rate limits that made conversational search impractical.

Third, mobile-first consumers now expect conversational interfaces. People text more than they call. They send voice notes. They interact with AI assistants daily. The behavioral shift happened. You no longer have to convince someone that talking to a computer is normal.

Any one of these alone wouldn't have been enough. Good LLMs without good data APIs give you a chatbot that can talk about travel but can't actually book anything. Good APIs without good LLMs give you the same form-based search we've had for twenty years. And both of those without a user base that's comfortable with conversational AI give you a product nobody adopts.

All three clicked into place around the same time. That's the window we built Nowah in.

## The conversation thesis

Let me get specific about why we think conversation is a better interaction model for travel booking. It comes down to four things the old model handles poorly.

**Ambiguity.** Most people don't start their travel search with a clear origin, destination, and date range. They start with something vague. "We want to do a beach trip sometime in April." A search form can't process that. A conversation can. We can ask follow-up questions, suggest destinations based on what we know about the user, narrow things down iteratively. The AI doesn't need perfect inputs to start being useful.

**Context accumulation.** In a traditional OTA flow, every search is stateless. You search for flights to Lisbon, then separately search for hotels in Lisbon, then look up things to do in Lisbon. Each search knows nothing about the others. In a conversation, context accumulates naturally. When you've already told us you're flying into Lisbon on April 3rd, we know where and when to search for hotels without asking again. We built an [agentic memory](/blog/agentic-memory-smarter-over-time) system specifically for this. It tracks your preferences, your trip context, and your past behavior so the AI gets better at helping you over time, not just within a single session but across your entire history with the product.

**Complexity reduction.** The more complex a trip gets, the worse traditional tools handle it. Try booking a multi-city trip with different travelers on different legs using Expedia. It's an exercise in frustration. In conversation, complexity is just more words. "I need to fly from New York to London on the 5th, then London to Paris on the 8th, and my wife is joining me in Paris so she needs a separate flight from Chicago." That's hard for a form. It's natural for a conversation.

**Preference matching.** Search forms let you filter by price, number of stops, and departure time. But most real preferences are harder to express. "I don't want to fly through Miami because the airport stresses me out." "I prefer hotels that feel local, not big chains." "I get claustrophobic so I need a window seat." An AI agent can absorb all of this and weight it in its recommendations. A filter dropdown can't.

When we track the metrics, the difference is visible. People using a conversational interface engage longer, explore more options, and — this is the one that matters — actually complete bookings at a higher rate. The industry-standard low-single-digit [OTA conversion](/blog/booking-conversion-rates-ai-agents) rate exists in part because the product does a terrible job of bridging the gap between "browsing" and "buying." Conversation closes that gap because the AI is actively moving you toward a decision instead of passively displaying options and hoping for the best.

## What Expedia, Booking.com, and Google got wrong

I want to be fair here. Expedia, Booking.com, and Google are not stupid companies. They have brilliant engineers and enormous resources. But they face a structural problem that we don't: they have to protect their existing business while trying to build the future.

Expedia makes money by showing you a lot of options and inserting sponsored placements and ads into those results. An AI agent that just tells you "book this flight, it's the best one" eliminates the surface area for that monetization model. So Expedia's AI features tend to be conservative, designed to enhance the browsing experience rather than replace it.

Booking.com has a similar tension. Their genius was the hotel listing page. Urgency signals ("Only 2 rooms left!"), social proof ("47 people looked at this in the last hour"), and comparison features. All of that disappears if the AI just picks the right hotel for you. Their AI trip planner is nice, but it feels disconnected from the actual booking flow because it kind of is.

Google's situation is different but equally constrained. Google Flights is a search product, and Google's business is search advertising. Google has been careful to make its AI travel features feel like enhancements to search rather than replacements for it. The AI-generated summaries sit on top of the traditional results. They point you toward the same links and listings that generate Google's revenue.

We don't have any of these constraints. We're not protecting an advertising business or a listing page or a legacy booking funnel. We designed Nowah from the ground up as a conversation-first product where the AI agent does the work and the user makes decisions instead of doing research.

That doesn't mean we got everything right on the first try. Building an AI-native travel product involves hard problems that don't have clean answers yet. How much should the AI decide vs. present options? When should it ask for confirmation vs. just act? How do you handle the inevitable cases where the AI misunderstands something? We're still iterating on all of this. But at least we're iterating on the right product instead of trying to graft a new paradigm onto an old one.

## Under the hood (without the jargon)

I won't bore you [with architecture](/blog/legacy-otas-struggle-with-ai-architecture) diagrams, but some of the technical decisions matter for understanding why the product works the way it does.

Nowah's AI agent isn't a simple chatbot that generates text responses. It's an orchestration system with a comprehensive suite of tools it can call. When you ask "find me flights to Tokyo in April," the agent doesn't just generate a plausible-sounding answer. It actually queries live flight APIs, processes the results, ranks them based on your preferences, and presents real options with real prices that you can book right there in the conversation.

This is harder than it sounds. The agent has to decide which tools to call, in what order, with what parameters, and then synthesize the results into a coherent response. It has to handle errors gracefully. It has to know when it doesn't have enough information and needs to ask you something. It has to manage state across a conversation that might span hours or days.

We built this on a streaming architecture. When you send a message, you see the agent thinking and responding in real time, including when it's searching for flights or checking hotel availability. There's no "please wait" spinner that comes back 30 seconds later with a wall of text. You watch the agent work, which builds trust and keeps you engaged.

The agentic memory system is the other piece that makes this work at a deeper level than a simple chatbot. Traditional chatbots are stateless or have very limited context windows. Ours remembers your preferences, your past trips, your travel patterns. It knows that you always book aisle seats. It knows you stayed at that hotel in Barcelona last year and liked it. It knows your passport expires in eight months and flags when a destination requires more validity than that.

We built the mobile app in a cross-platform mobile framework, and we're running a web framework web client alongside it. a single typed language across the stack everywhere. a relational database for structured data, an in-memory data store for real-time state. The backend is Node.js with Express. Nothing exotic in the stack, because the innovation isn't in the technology choices — it's in how we assembled them around a conversational interaction model instead of a search-and-browse one.

## Where this goes next

Here's where I get to speculate a bit, which is the fun part.

Right now, Nowah is a very good travel assistant. You tell it what you want, it finds options, you make decisions, it books. That's already better than the 38-tab alternative. But the trajectory we're building toward is more interesting.

The next phase is an AI agent that doesn't just respond to your requests but anticipates them. You booked a flight to Rome in April. The agent knows you like boutique hotels in walkable neighborhoods. It knows your budget range from past trips. It knows you're traveling with your partner who is vegetarian. Before you even ask, it can suggest hotels, make dinner reservations at restaurants with good vegetarian options, and flag the museum exhibit that's only running during your dates.

Beyond that, we're working toward an agent that can handle changes and disruptions autonomously. Your flight gets delayed and you'll miss your connection? The agent rebooks you before you even realize there's a problem. Hotel overbooked? Alternative already found and confirmed. This requires a level of trust between user and agent that takes time to build, and we're designing the product to earn that trust incrementally.

The end state, and this is years out but worth stating, is a fully autonomous travel agent that handles your entire travel life. You tell it "plan our anniversary trip" and come back to a fully booked itinerary that accounts for everything it knows about you and your partner. You get on the plane, and the agent manages everything else in the background.

That sounds like science fiction, but every individual capability it requires already exists or is close to existing. The challenge is reliability. An autonomous agent that gets it right 90% of the time isn't good enough for travel because the 10% failure case means you're stranded in an airport or sleeping in a hotel you hate. We need to get to 99.9% before full autonomy makes sense, and that's a multi-year engineering problem.

In the meantime, the product gets better every week. Every conversation teaches the agent something. Every booking refines the recommendation logic. Every piece of user feedback tightens the gap between what people want and what the AI delivers.

## Why this matters beyond travel

One more thing. What we're building at Nowah is a specific application of a general trend: replacing passive software that displays information with active agents that do work on your behalf. Travel is a great proving ground for this because the problem is well-defined (get a person from A to B with a place to sleep), the data is available, and the user pain is acute.

But the pattern applies everywhere. Insurance. Real estate. Healthcare. Legal. Any industry where consumers currently face an overwhelming number of options and insufficient tools to navigate them is ripe for the same transformation.

We picked travel because we love travel and because we were personally frustrated by how bad the tools were. The market size didn't hurt either. The AI-in-travel market is projected to exceed $1.2 billion by 2028, and that estimate might be conservative given how quickly the technology is improving.

But the bigger bet is that the interaction model we're building, conversation-first, agent-driven, memory-enabled, becomes the default way people interact with complex services. The search form had a good run. It's time for something better.

We're building that something. And if you've ever rage-closed your 38th browser tab while trying to book a flight, you know exactly why.

---

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).