Our Tech Stack: Why We Are Choosing What We Choose

Every technology choice is a bet. You are betting that a language, framework, or database will serve you well not just today but as the product evolves over years. You are betting on ecosystem maturity, hiring pool depth, performance characteristics, and developer experience.

Here is our full stack and the reasoning behind each decision.

The meta-principle: developer velocity above all

The single most important metric for an early-stage startup is how fast you can go from idea to shipped feature. Every technology choice should optimize for this. Performance matters. Scalability matters. But velocity matters most in the early years because the product is still finding its shape, and every week of delay is a week of learning you miss.

a single typed language across the stack everywhere

We use a single typed language across the stack across the entire stack: frontend, backend, mobile, and AI agent configuration. One language reduces context-switching for every engineer. You do not lose thirty minutes reorienting your brain when you shift from the backend to the mobile app. The mental model stays consistent.

a single typed language across the stack specifically gives us type safety without the overhead of a compiled language. Type errors caught at build time are bugs avoided at runtime. For an AI product where so much data flows between services, knowing the shape of every object at every boundary is enormously valuable.

It also simplifies hiring. We need generalists who can work across the stack. A single language means every candidate who knows a single typed language across the stack can contribute everywhere.

the mobile app framework and the mobile build tooling for mobile

We chose a cross-platform mobile framework for our mobile app. The decision came down to one thing: we needed iOS and Android from a single codebase, and we needed to move fast.

Native development in Swift and Kotlin would give us marginally better performance and platform-specific polish. But it would double our mobile engineering effort. Every feature would need to be built twice. Every bug fixed twice. Every design decision implemented in two different paradigms.

the mobile build tooling specifically adds a layer of developer experience that accelerates mobile development dramatically. Over-the-air updates, simplified build configuration, and a rich set of pre-built modules mean we spend time on product, not on native platform plumbing.

The trade-off is performance. For a conversation-based app, the performance difference between the mobile app framework and native is negligible. We are not building a game or a video editor. We are building a messaging interface that displays text, cards, and booking confirmations. the mobile app framework handles this perfectly.

the web framework for web

Our web application runs on the web framework with the app router. Server components, server-side rendering, and edge runtime support give us performance and SEO benefits that matter for a web product that needs to be discoverable.

The web serves a different purpose than the mobile app. Mobile is the core experience, the app you use daily. Web is the growth and research channel, where new users discover Nowah and where existing users handle complex tasks on a larger screen.

Both platforms share the same backend API and AI agent. A user can start a conversation on the web and continue it on mobile. The experience is consistent because the intelligence layer is identical.

a relational database for data

We chose a relational database over NoSQL for our primary database. Travel data is inherently relational. A trip has flights. Flights have passengers. Passengers have preferences. Hotels have bookings. Bookings have payments. These are relationships, and a relational database handles them more naturally than a document store.

Our ORM provides type-safe database queries that catch errors at build time. Schema migrations are versioned and reproducible. The visual database browser accelerates development by letting us inspect data without writing queries.

an in-memory data store for real-time state

an in-memory data store handles our real-time concerns: job queue state, caching, and ephemeral data that needs to be fast and does not need durability. Seven background job queues process tasks like confirmation emails, document generation, and analytics aggregation.

The combination of a relational database for durable data and an in-memory data store for ephemeral state gives us the right tool for each job without over-engineering either.

The AI model choice

Choosing which AI model powers the agent is the most consequential technology decision we make. We evaluate on five axes: accuracy, latency, cost per query, tool use reliability, and reasoning depth.

The model must handle complex multi-step tool chains. A typical travel query involves searching flights, filtering by user preferences, checking hotel availability, reasoning about trade-offs, and presenting a coherent recommendation. This is not simple text generation. It is orchestrated reasoning across multiple data sources.

We chose the model that best balanced these axes for our specific use case. Benchmark scores are a starting point, but real-world travel evaluations are what determine the final choice. The model landscape changes monthly, so we maintain the flexibility to switch or upgrade as better options emerge.

What we would change

If we started over today, we would invest in our streaming architecture earlier. Streaming ended up being one of the most important product features, and we initially treated it as an optimization rather than a core requirement.

We would also set up our evaluation framework from day one. Testing AI products requires a fundamentally different approach, and the sooner you have a robust eval pipeline, the faster you can iterate with confidence.

The stack itself, a single typed language across the stack, the mobile app framework, the web framework, a relational database, an in-memory data store, we would choose again. Not because it is the only valid option, but because it optimizes for the thing we care about most: the speed at which a small team of generalists can build, iterate, and ship a complex product.

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.