Deal Engine

FlightHub's production flight inventory held a very large number of prices, but price alone does not tell you whether a fare is a good deal. A fare that looks cheap on one route can be ordinary on another, and the same price means something different depending on when someone is travelling and how that route has been priced before.

The merchandising team needed a consistent way to rank relative value across that inventory. Without one, choosing which fares to feature meant selecting from a large inventory by hand, and the result depended on who was looking and when. Doing that well by hand across a large, constantly changing inventory is not realistic, and doing it inconsistently means the featured deals are only as good as the last person's judgment. The question the system had to answer was narrow: for this route and this travel context, how competitive is this price?

I built Deal Engine in FlightHub's Solutions Lab. It analyzes live inventory against three kinds of context: the route, the timing of travel, and historical pricing. From that, it scores each fare on relative value rather than absolute price, so a fare is judged against what is normal for its own route and travel context instead of against the whole catalogue.

The engine runs continuously. As inventory changes, fares are rescored and the ranking is rebuilt, so the list of deal candidates reflects current prices rather than a stale snapshot. The output is an ordered feed of deal candidates that downstream merchandising surfaces read. Those surfaces select from the top of a consistent ranking instead of from the raw inventory. Because every fare is scored against the same kinds of context, the ranking stays consistent from one refresh to the next and from one route to another.

The most useful design decision was keeping the engine's job small. It ranks the inventory that exists. It does not set or change fares. Its job is to turn a very large inventory into one consistent, ranked input for the surfaces and people downstream. Keeping that boundary clear made the output easier to reason about and easier to check: a ranked candidate either reflects the route, timing and price history it was scored against, or it doesn't.

It is also the kind of problem I look for in operations work generally. A team faces a pile of options, each decision is made by hand, and the quality of the choice depends on who is looking. A system that applies the same context to every option, every time, doesn't replace the people who decide what to feature. It gives them a ranked starting point they can trust and question.