Our Engineering Principles for Building AI Products

Principles are only worth writing down if they actually change behavior. If a principle is so generic that any company would agree with it ("we value quality"), it is not a principle. It is a platitude. The principles I am sharing here are ones that have concretely changed how we make decisions, and some of them are positions that reasonable people might disagree with.

AI is the product, not a feature

This sounds obvious for an AI company, but the implications are surprisingly far-reaching. When AI is a feature, it is optional. The product works without it, and the AI makes it better. When AI is the product, every system must be designed with AI in the critical path.

This means our database schema is designed for the queries the AI agent needs, not the queries a traditional search page would need. Our APIs return data in formats the agent can reason about, not just formats the UI can display. Our error handling surfaces enough context for the agent to make decisions, not just enough for a human to read an error message.

It also means AI reliability is product reliability. If the AI model is slow, the product is slow. If the AI makes a bad recommendation, the product made a bad recommendation. There is no fallback "normal mode" that works without AI. This raises the bar for everything from latency optimization to quality assurance.

Every engineering decision starts from this premise. "How does this affect the AI agent?" is the first question we ask about any architectural change, not an afterthought.

Ship fast, measure everything, iterate

Speed matters in a market where the underlying technology improves weekly. An AI product that ships a feature today has a learning advantage over one that ships the same feature in three months. Three months of production data, user feedback, and iterative improvement compounds into a meaningfully better product.

But speed without measurement is just moving fast in a random direction. We ship features behind metrics. Every feature has success criteria defined before it ships. Conversation quality scores for agent changes. Booking completion rates for flow changes. Response latency for infrastructure changes.

When a feature does not move its target metric, we either iterate or kill it. We have killed features that took weeks to build because the metrics said they did not work. That is painful in the moment but prevents the slow accumulation of complexity from features that do not earn their keep.

We run continuous evaluation through our CI/CD pipeline. AI eval suites gate every deployment. If an agent change degrades conversation quality below our threshold, it does not ship. This is the measurement infrastructure that makes fast shipping safe.

Reliability is not negotiable for financial transactions

When an AI agent handles real money, the reliability standard is different from a chatbot that gives bad advice. Bad advice is embarrassing. A double-charged flight is a support ticket, a refund process, and an erosion of trust that takes months to repair.

We treat booking reliability as a hard constraint, not a goal. Multi-layer idempotency ensures no duplicate bookings. Saga patterns ensure no partial bookings leave users in an inconsistent state. Full audit trails ensure every financial action can be traced and explained.

This principle has real cost. Idempotency logic adds complexity to every endpoint in the booking flow. Saga orchestration adds infrastructure that a simpler system would not need. Audit logging adds storage and processing overhead. We accept these costs because the alternative, a system that occasionally fails in ways that affect users' money, is not acceptable.

I sometimes frame it this way: if you would not be comfortable explaining a system failure to a user whose credit card was charged for a booking that did not exist, the system is not reliable enough.

a single typed language across the stack everywhere for team velocity

This is an opinionated choice that some engineers will disagree with. a single typed language across the stack is not the best language for any single task. It is not the fastest runtime. It is not the most expressive type system. It is not the best language for AI/ML work.

But it is the best language for our team's total velocity across the full stack. One language means one set of skills to hire for. One set of tooling to maintain. One type system that flows from database schema to API to frontend. Zero language context switches when an engineer moves between parts of the system.

a single typed language across the stack across the full stack gives us type safety and velocity as compounding advantages. Over time, the shared types prevent more bugs, the familiar patterns make new features faster, and the consistent tooling reduces operational overhead. The gains are not dramatic in any single week. Over months and years, they are significant.

User trust is the most important metric

This is the principle that sits above all the others. Every technical decision ultimately exists in service of user trust.

We measure trust through proxy metrics: booking completion rates (do users follow through?), return usage (do users come back?), and support escalation rates (do users need human help?). These metrics are imperfect proxies, but they are the best signals we have for whether users trust the AI agent with their travel.

Trust influences our technical decisions in specific ways. We show the agent's reasoning for recommendations because transparency builds trust. We require explicit confirmation before any payment because control builds trust. We maintain human support as a fallback because safety nets build trust. We send detailed booking confirmations because accountability builds trust.

Trust is also why we invest in the less visible infrastructure: audit trails, saga patterns, monitoring, alerting. Users do not see these systems directly. But they feel the difference between a product that handles edge cases gracefully and one that breaks when something unexpected happens.

These five principles are not aspirational. They are operational. They change how we write code, how we review pull requests, how we prioritize the roadmap, and how we respond to incidents. If they were not changing behavior, they would not be worth having.

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.