Building an Award Flight Finder: What I Learned Turning 365 Date Checks Into One Search

Curtis Zhang — Tue, 08 Sep 2026 05:53:58 +0000

Reward flights are one of those problems that look simple until you try to build a useful search experience around them.

A traveller usually starts with a straightforward question:

“Which dates can I fly this route using miles?”

But airline websites often make people check one date at a time. Availability changes frequently, different cabins behave differently, and a seat that appears today may be gone tomorrow. The user does not really want another booking form. They want a fast way to understand a large, changing set of dates.

While building MileSeat, I learned that the best interface for this problem is not a conventional list of search results. It is a calendar, supported by filters and alerts.

Start with the real user job

The obvious product brief is “build an award flight search tool.” That description is too broad to guide many design decisions.

The actual job is closer to this:

Check a route across a wide date range.
See which dates have seats in the desired cabin.
Compare nearby dates without repeating the search.
Return later when availability changes.
Complete the redemption on the relevant airline or loyalty-program website.

This framing matters. MileSeat is not an airline or a travel agent, and it does not complete bookings. Its job is to reduce the discovery work before booking.

A year is a better unit than a single date

Most flight forms begin with a departure date. That works well when cash fares are widely available and the user is optimizing price or schedule.

Award travel is different. Availability itself is often the constraint.

If someone wants two Business Class award seats between London and New York, asking for one exact date too early can hide the useful answer: there may be no seats on Friday, but there may be seats on Thursday or Sunday.

That led us toward a 365-day calendar view. A calendar changes the interaction from repeated querying into visual scanning. Users can identify clusters, gaps, and nearby alternatives without submitting dozens of nearly identical searches.

The broader product lesson is simple:

When flexibility is part of the user's strategy, show the whole decision space before asking them to narrow it.

Availability and price are different questions

Another important distinction is the difference between award-seat availability and the final redemption price.

A seat can be available while the number of points, taxes, fees, or booking rules vary by program. Partner-airline access can differ as well. Trying to compress all of that into a single “best deal” number creates false certainty.

A clearer flow is:

Find dates with award seats.
Filter by airline, route, cabin, and number of seats.
Confirm the current points price and fees with the program used for booking.
Complete the redemption on the official site.

Keeping these stages separate makes the product easier to explain and reduces the risk of users treating an availability signal as a guaranteed booking quote.

Filters should reflect traveller decisions

A technically impressive filter is not necessarily a useful filter. The highest-value controls are the ones that map directly to decisions travellers already make:

Origin and destination
One-way or return
Economy, Premium Economy, Business, or First Class
Number of seats
Airline or loyalty-program context
Flexible date range

The number-of-seats filter is especially important. Showing a date with one seat is not useful to a couple looking for two. The calendar should reflect the party's actual requirement rather than presenting any positive inventory as a match.

Alerts complete the workflow

A search only answers “what is available now.” For popular premium cabins, that is often not enough.

Availability can return after cancellations or inventory updates, so the product needs a second mode: monitoring. A traveller specifies the route, cabin, date range, and seat count, then receives an alert when a matching result appears.

This is more than a notification feature. It changes the product from a one-time query tool into an asynchronous workflow:

Search now → no suitable dates → save criteria → monitor changes → notify when a match appears.

For products built around volatile data, the same pattern can be useful in many domains: appointments, event tickets, rentals, inventory, and pricing.

What I would measure

A search product can easily optimize the wrong metric. Page views alone do not tell you whether people found a usable result.

The more meaningful signals are:

Percentage of searches that return at least one matching date
Time from landing to the first calendar result
Filter changes after results appear
Alert creation following a search with no suitable result
Return visits from an alert
Outbound clicks to continue the booking process

These metrics follow the user's progress rather than the site's content volume.

The main takeaway

The biggest lesson from building MileSeat is that search UX should match the shape of the underlying decision.

For award travel, the user is not choosing from a stable list. They are exploring sparse availability across time. A full-year calendar makes that structure visible, while cabin and seat-count filters make it relevant. Alerts handle the fact that the answer can change after the user leaves.

If you are building any product around limited, changing availability, begin by asking whether users really want a better search box—or a better view of the entire opportunity space.

You can see the current implementation at MileSeat.

DEV Community: Curtis Zhang