HamroTrips — Online Travel Agency (Nepal)

The problem

Booking a flight out of Kathmandu is not the same transaction as booking one out of London, and the difference is in the fare rather than the interface.

Price depends on who is flying. A Nepali passport and a foreign one are quoted differently on the same seat, and there are separate fare categories for students and for migrant workers travelling for employment — a large share of outbound traffic from Nepal. None of that is an edge case here; it is the first question the search form has to ask, which is why nationality and fare category sit in the search bar next to cabin class rather than behind a passenger detail step.

The other half is that the agency does not only sell online. Walk-in and phone customers are still a large part of the business, so whatever the website can book, a staff member has to be able to book too — from the other side, on the customer's behalf.

Where the flights come from

The inventory is not ours. Schedules, live pricing and seat availability arrive from Amadeus and Plazmatec — a global distribution system and a consolidator — alongside the other integrations the platform runs, four or more in total.

That is the fact that shapes the front end. Nothing in a flight result is static: a fare quoted on the results page can be gone by the time someone reaches payment, two sources can offer the same physical seat at different prices, and each returns its own shape of data. The interface has to present one coherent list of airlines and fares out of that, and it has to be honest about the fact that the number on screen is a quote rather than a promise.

What the platform does

On the customer side: flight search across one-way, round-trip and multi-city itineraries, with cabin class, passenger mix, nationality and fare category applied to the query rather than filtered afterwards. Around it sit hotels, curated holiday packages, a catalogue of 80-plus destinations and promotional deals, plus accounts for returning travellers and a payment step with several methods behind it.

Behind that, the admin panel is the same product from the agency's side: staff browse the airlines available for a route and place a booking directly against a customer, so a phone enquiry ends in the same record as a self-service booking rather than in a separate spreadsheet.

What I owned

I built customer-facing screens against the supplied designs, working to a pixel-accurate reproduction of the comps rather than an approximation — the brief was that the built page and the design file should be indistinguishable.

On the admin panel I owned two pieces. Permission management: which staff role can see and do what, enforced in the interface so a user is never shown a control they cannot use. And airline listings: presenting the airlines available for a given route out of the upstream responses, in both directions of the product — the customer's own booking flow and the direct booking an admin makes for someone else.

Those two flows share an inventory source and had to stay consistent, because an airline or a fare that appears in one place and not the other is a support call, and on a platform taking thirty-odd bookings a day that is a support call every day.

Why it is built the way it is

A Next.js front end over a Ruby on Rails backend on AWS and PostgreSQL. Server rendering matters more than usual here: travel is a category people arrive at from Google, and a destination or route page that renders on the server is one that can be indexed and shared.

Tailwind is what made the pixel-accuracy brief tractable. Reproducing a design exactly is mostly a spacing and type-scale problem, and having those as a fixed set of tokens rather than hand-written values per component is what keeps the twentieth screen as close to the comp as the first.

TypeScript earns its place where the fares are. A search carries nationality, fare category, cabin class and a passenger breakdown from the form through to the results and into the booking, and it does that across responses from more than one upstream provider. Those combinations are the part of this product where being quietly wrong costs someone money.