--- title: "Building for the Web: Why We Chose a Server-Rendered Travel Booking App" description: "The web app launch story — why a full browser experience instead of a mobile wrapper, architectural choices, and how web serves different travel use cases." canonical: https://nowah.xyz/blog/launching-web-nextjs-travel-booking-app lastModified: "2026-08-07T08:24:30.643Z" --- # Building for the Web: Why We Chose a Server-Rendered Travel Booking App The web app launch story — why a full browser experience instead of a mobile wrapper, architectural choices, and how web serves different travel use cases. A traveler told us: "I love the app but I need a big screen to compare five flights side by side." She was planning a family reunion with flights from four different cities, and the mobile chat interface, while great for sequential conversation, was not designed for parallel comparison. That feedback crystallized something we had been discussing internally. Mobile is the best platform for quick interactions: checking a flight status, booking a simple trip, pulling up a boarding pass. But the planning phase of travel, when you are comparing options, reviewing hotel photos, and building an itinerary, benefits enormously from screen real estate. We did not want to wrap the mobile experience in a browser frame. We wanted a full web application that serves the use cases where a bigger screen genuinely helps. ## Architecture decisions ![Illustration for this section](https://pics.nowah.xyz/website-media/launch-013-img-1.webp) We built the web app with the web framework using the App Router for file-based routing. The same AI agent backend serves both the mobile app and the web app. Same reasoning engine, same tools, same memory system, same booking infrastructure. The difference is purely in the frontend. The web client communicates through an edge runtime API proxy that handles authentication and request forwarding. This lets us keep the backend API clean and consistent while the proxy handles web-specific concerns like cross-site request forgery protection and cookie management. For the AI conversation, we implemented server-sent events streaming through the browser's fetch ReadableStream API. The same streaming callbacks that work on mobile, where the traveler sees the agent thinking and responding in real time, work on web with a different transport layer. The result is 18 clean routes at build time with zero a single typed language across the stack errors. Route groups separate consumer-facing pages from business pages from authentication flows, keeping the codebase organized as it grows. ## The planning versus booking divide Usage data confirmed our hypothesis. Web users spend more time in the planning phase. They compare more options, view more hotel photos, and interact with [itinerary generation](/blog/launching-itinerary-generation-ai-plans-trip) more heavily. Mobile users are more transactional. They search, select, and book with fewer comparison steps. This is not because web users are different people. They are often the same travelers at different points in their journey. They plan on their laptop in the evening and book on their phone during lunch. The web app and mobile app serve different moments in the same traveler's workflow. We designed the web interface to support this planning behavior. Flight and hotel cards display with more detail on web, including side-by-side comparison views that do not exist on mobile. Hotel photo galleries are larger. Itinerary views use the full width of the screen to show daily plans with maps. The chat interface is still the core of the web experience because conversation remains the best way to interact with the agent. But the response cards that the agent generates take advantage of the larger canvas to show more information without requiring the traveler to tap through to detail screens. ## SEO considerations ![Supporting diagram](https://pics.nowah.xyz/website-media/launch-013-img-2.webp) A chat-first product presents an interesting SEO challenge. Search engines cannot crawl a conversation. The valuable content is generated dynamically in response to traveler queries, not sitting on static pages waiting to be indexed. We handle this through server-side rendering for our content pages and standalone tools. The currency converter, tip calculator, and bill splitter are fully rendered server-side and serve as high-intent SEO entry points. A traveler who finds our currency converter through a search engine is one interaction away from the chat interface where the agent can help with their broader travel needs. The web app is not just a bigger version of the mobile app. It is a complementary surface that serves different moments in the travel workflow, attracts different traffic through SEO, and provides capabilities that a phone screen cannot comfortably accommodate. Together, the mobile and web experiences cover the full spectrum of how travelers research, plan, book, and manage their trips. --- 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).