Moorexplore: A travel discovery platform that finds where to go

01 / Overview

About Moorexplore

02 / The challenge

What Moorexplore needed to solve

Recommending a destination is harder than listing hotels, and every recommendation needs real prices and current safety advice behind it.

1. 01

   Loose preferences like "warm, quiet, great food" had to become a ranked list of destinations people could trust.

2. 02

   Live prices had to come from slow outside suppliers within a five-second target.

3. 03

   Government safety advice changes often, and every change needed a person to review it before it reached travelers.

4. 04

   Several editors needed to update destination content at the same time without overwriting each other's work.

03 / What we built

How we built Moorexplore

We built the core platform as a typed Node.js and TypeScript API, starting from an OpenAPI 3.1 contract where every requirement maps to a module and a test.

• 01

  Destination discovery engine

  The engine scores destinations against the traveler's budget, dates, departure city and preferences. Each match shows a fit score and the reasons it was picked, so travelers can see why Seville or Valletta made the list.

• 02

  Free-text wishes with OpenAI

  Travelers can type something like "somewhere quiet with great food". OpenAI turns that into structured preferences the engine can score against.

• 03

  Live flight and stay search

  Flights and stays for each matched destination are searched together through Duffel. Estimated prices on the match cards become live prices once the traveler asks for them.

• 04

  Helpful empty states

  When fewer than three destinations survive the filters, the platform explains why and suggests the fix, like raising the flight budget, trying nearby dates or allowing indirect flights.

• 05

  Separate flight and stay bookings

  The stay and the flight are booked and paid for separately, each direct with its provider. Travelers can book both or either one alone, and each booking has its own cancellation terms.

• 06

  Reviewed safety advice

  A scheduled job reads UK Foreign Office travel advice and sends any change to an editor's review queue. Travelers see current advice that a person has checked.

• 07

  Editor tools for destinations

  Editors manage destination content without overwriting each other's changes, so several people can work on the catalog at once.

• 08

  Queued background work

  Email, safety checks and supplier webhooks run in BullMQ queues on Redis. Slow supplier responses and retries do not hold up the traveler's search.

04 / The results

What changed for Moorexplore

By mid-August 2026, the identity, destination management, discovery and travel search modules were complete and tested.

• 67 routes were live, built against a 28-endpoint API contract.
• Moorexplore's own processing takes 23 milliseconds per search, and the rest of the wait is supplier response, which the team measured and documented.
• Every requirement is traced to a module and a test, so the client can see exactly what has been built and verified.
• Checkout was fully specified and queued as the next milestone.