The situation
Booking travel online usually means doing the work yourself: search, filter, compare, repeat. And the moment a trip becomes anything other than simple — a family of six, a multi-city route, a specific hotel district, a budget that has to hold — the search boxes stop helping.
Meanwhile, travel agencies already solve exactly these problems every day. What they didn't have was a channel that reached travellers at the moment of intent.
Terhal inverts the usual model. The traveller doesn't search. They describe the trip they want — destinations, dates, budget, who's going, what matters to them — and post it as a request. Agencies respond with real proposals. The traveller compares actual offers rather than raw inventory, picks one, pays on the platform, and receives their tickets there.
One marketplace, two sides, and a complete journey from "I want to go somewhere" to a ticket in hand — without a single phone call.
How we built it
The traveller's side: describing a trip, not searching for one
The request flow had to capture enough detail for an agency to quote accurately, without turning into a form nobody finishes. We designed it around the way people actually describe trips — destination and dates first, then the details that shape the price — so a complete, quotable request takes a couple of minutes rather than twenty.
The agency's side: quoting fast enough to win
In a marketplace where proposals compete, speed of response is the product. We built agency tooling around one goal: see a new request, understand it immediately, and send a complete proposal in minutes — with saved templates, reusable components, and everything needed to quote sitting on one screen.
The middle: comparison, payment, and delivery
Proposals from different agencies are structured so they can genuinely be compared — not just on price, but on what's actually included. Payment happens on the platform, and tickets are issued and delivered there too, so the transaction never leaves the system that produced it.
The hard part
Two technical problems defined this build — and both had to be solved for the concept to work at all.
Response speed
A marketplace built on proposals lives or dies on how fast those proposals arrive. A traveller who posts a request and hears nothing for a day has already gone elsewhere. That made latency a product requirement rather than a performance target: requests had to reach the right agencies instantly, notifications had to be immediate and reliable, and every screen an agency touches while quoting had to respond without a wait. We designed the request distribution and notification layer around that constraint from the start, rather than optimising it afterwards.
Flight and hotel room data
The second problem is the one every travel platform underestimates. Flight and hotel inventory is enormous, changes constantly, arrives from multiple sources in inconsistent shapes, and is only ever briefly true. Availability and pricing can move between the moment an agency builds a proposal and the moment a traveller accepts it.
Handling this meant treating data freshness as a first-class concern — how inventory is fetched, how long it can be trusted, how it's cached, what happens when a source is slow or unavailable, and how a proposal behaves when the underlying availability shifts underneath it. Getting this wrong doesn't produce a slow platform. It produces a platform that sells things that no longer exist.
The outcome
Terhal works as a complete loop: a traveller describes a trip, agencies compete for it with real offers, and the winning proposal turns into a paid ticket without anyone leaving the platform.
It's a harder product to build than a search box — which is exactly why it's a different one.
