The Problem We Didn't See at First

We started with a seed dataset covering 60+ countries because we needed enough destinations to get the product working.

As we ran more user cases, a pattern emerged: despite changing user preferences and constraints, the system kept recommending the same handful of destinations.

1. What Does "A Great Recommendation" Actually Mean?

The ideal experience for our users is when they give us their constraints, we understand what matters to them, then consider a sufficiently broad universe of possibilities before finding a trip that would genuinely be relevant to them. A quantifying action to prove its usefulness would be that users ‘save trips’ rate, ‘minor adjustments’ rates and eventually booking rate.

It would be sad for us to see users leaving the trips under ‘Suggestions’ instead of ‘Saved’, or worse, if users decided to delete a good majority of the trips without saving any.

As we run through different user case scenarios, we learned that a recommendation cannot be highly relevant if the system never considers the right possibilities.

It is important for us to ensure adequate depth (where all constraints and considerations important to a real user) and breadth (the variety of options we could propose) are well delivered.

2. The Personalisation Problem Has Two Sides

A useful recommendation is not just about understanding the user better. It also depends on how many relevant possibilities the system has available to consider.

I started thinking about this as two dimensions of personalisation: depth and breadth.

Depth: How well do we understand the user?

This is the part we had been actively improving.

For each trip generation, we progressively capture more of the user's constraints and preferences:

• Travel dates and available leave
• Budget
• Visa constraints
• Preferred travel "vibes"
• Activities and interests
• Travel preferences
• Other trip-specific requirements

The goal is to move from:

"What destination does this person generally like?"

to:

"Given everything this person needs for this particular trip, what would actually work for them?"

This matters because a recommendation can only be genuinely useful if it respects the user's real-world constraints.

Breadth: How many possibilities can we consider?

But there is another side to personalisation:

"Given everything we know about this user, how large and diverse is the universe of possibilities we're considering?"

This was where the travel web app was weaker.

We started the product with a relatively small seed dataset of 60+ countries. That was sufficient to build and test the core recommendation pipeline, but as we began running more user scenarios, a pattern became increasingly obvious:

Different users with meaningfully different preferences were often being recommended the same handful of destinations.

The problem wasn't necessarily that those destinations were bad recommendations. They could still satisfy the user's constraints.

The problem was that the system had too few possibilities to choose from.

The two dimensions work together

I think about recommendation quality as the intersection of these two dimensions:

	Narrow breadth	Broad breadth
Shallow understanding	Generic, repetitive recommendations	More options, but poorly personalised
Deep understanding	Highly constrained, but limited possibilities	The target experience
		Deeply personalised recommendations from a rich universe of possibilities

We had been moving down the depth axis: getting better at understanding what the user actually needs, but not far enough along the breadth axis.

That created an important product constraint:

We could become increasingly precise about what the user wanted, but still struggle to find something surprising, distinctive, and genuinely relevant if the right possibilities weren't in our recommendation universe.

This changed how I thought about the problem.

The goal is to build a recommendation universe that is broad enough to enable discovery, but structured and high-quality enough that the AI can still make highly relevant recommendations, not simply adding more destinations.

That's the balance we need to solve next.

3. Why Repetition Is a Product Problem

At first, repeatedly recommending the same destinations can seem harmless if those destinations are genuinely good matches.

But for a travel product, discovery is part of the value proposition.

If users repeatedly see the same destinations despite changing their preferences, the product can start to feel predictable. Over time, users may question whether the system is actually considering their inputs or simply choosing from a fixed set of popular options.

This matters particularly because our longer-term product vision is not just to generate an itinerary. We want users to think:

"This understands what I need, and I hadn't necessarily thought of this trip myself."

A narrow recommendation universe makes that increasingly difficult.

So breadth is not a vanity metric like "number of destinations supported". It is part of the product's ability to provide useful discovery and maintain recommendation quality over repeated use.

4. Diagnosing the Root Cause

The root cause became fairly straightforward once we looked at the recommendation pipeline.

Our current flow is roughly:

User constraints
      ↓
Deterministic hard filtering
      ↓
Destination database
      ↓
Candidate destinations
      ↓
Claude ranking
      ↓
Final recommendations

The hard-filtering layer is intentionally conservative. It removes destinations that clearly don't satisfy requirements such as budget, dates, leave days or visa feasibility. Claude then ranks the remaining candidates based on the user's preferences.

The problem is that Claude can only choose from the candidates we give it. Our initial destination dataset was created to get the product working, rather than to provide comprehensive global coverage. With only 60+ countries represented, the effective search space could become quite narrow after applying a user's constraints.

This led to an important distinction:

The model wasn't necessarily making poor decisions. We were sometimes asking it to make the best decision from an insufficient set of possibilities.

That meant improving prompts or asking more questions would only take us so far. We also needed to improve the breadth of the underlying recommendation universe.

The Market Gaps

The current system, covering 64 destinations, fails to comprehensively serve three distinct market segments in our MVP round. Based on online information and understanding of these users, we assumed generically what type of travels would be popular amongst users from different countries.

1. SG users (where I’m based in): The system lacks Southeast Asian depth, has no China tier-2 cities, and omits Central Asia/Silk Road.
2. USA users: Domestic and regional options are sparse, there is no New Zealand coverage, and multi-city road-trip support is weak.
3. Global explorers: The system does not support overland expedition routes or self-drive scenic paradigms.

More fundamentally, the architecture assumes one travel paradigm (efficient rail), but global markets use 4 distinct paradigms with different transport logic and multi-city patterns.

In this scenario, we did not consider users from a ‘jobs to be done’ or ‘user profile’ (the more typical PM angle) as we had to tackle the issue from a more pragmatic perspective, taking into account a good variety of travel interests, location distances considerations and real-life trip considerations in terms of budget, time and distances.

5. Why We Didn’t Just "Add More Places"

The obvious solution was to add more destinations, but simply increasing the number of rows in the database does not automatically create better recommendations.

Every destination needs enough structured information for the system to determine whether it is actually relevant:

• Budget
• Visa feasibility
• Seasonality
• Weather
• Activities and interests
• Travel style
• Geographic location
• Other attributes relevant to matching

And as we move towards more advanced planning, we also need to understand how destinations relate to one another.

For example, knowing that Bangkok and Chiang Mai are both good destinations is different from knowing that they can form a sensible combination for a seven-day trip.

This led to a broader question:

What should our destination knowledge layer represent if we want the AI to eventually reason about not just destinations, but combinations of destinations?

6. Designing a Broader Recommendation Universe

I therefore started thinking about the destination database less as a static list and more as a knowledge layer for the recommendation system.

At the simplest level, each destination needs useful attributes:

Destination
├── Location
├── Budget
├── Visa
├── Weather
├── Seasonality
├── Vibes
├── Activities
└── Other travel attributes

But for richer recommendations, we also need relationships between destinations.

For example:

Bangkok
├── Chiang Mai
├── Phuket
└── Siem Reap

Tokyo
├── Kyoto
├── Osaka
└── Hakone

These relationships could eventually capture things such as:

• Geographic proximity
• Transport connectivity
• Typical travel time
• Regional relationships
• Commonly combined destinations

The objective isn't to give Claude a broader but meaningful search space.

A key problem observed: A Paradigm-Blind Architecture

From a practical perspective, most people seldom plan multi-cities trip that would require a long day of commute. There are exceptions to it, but most of the time such arrangement would not be time and effort efficient. Thus, we set a 4-hour city to city commute duration rule for multi-city planning.

The current 4-hour max-commute rule works for Gao Tie (China), TGV (Europe), and Shinkansen (Japan), but it systematically fails for three other travel patterns:

• Island-hopping (SE Asia, Hawaii): Realistic commutes are 3–3.5 hours, yet many valid routes are rejected.
• Self-drive scenic (New Zealand, USA coasts): 6–8 hour drives are the attraction itself, not wasted time.
• Overland explorer (Central Asia, Africa): 8–16 hour journeys are expected, and Silk Road expeditions require this.

Specific routes that our 4-hour rule rejected incorrectly:

Route	Travel Time	Why it's rejected	Why that's a problem
Beijing ↔ Xi'an	11.5h (Gao Tie)	Violates 4h rule	This is the cultural history route.
Auckland → Rotorua → Taupo	8.5h driving	Violates 4h rule	This is the New Zealand road-trip experience.
Samarkand → Bukhara → Khiva	10–12h drives	Violates 4h rule	This is the Silk Road canonical route.

The Hard Filtering Reality (Before Structural Fixes)

To understand why recommendations were narrow, we measured candidate pool survivability across 10 representative scenarios. The filtering rules (budget, proximity, weather, duration) routinely eliminated 15–30 destinations, leaving only 28–52 survivors.

Scenario	Initial Pool	Survivors (After Filtering)	Pass Rate
4-day, $2000, Feb (SG passport)	64	~36	56%
7-day, $3000, Feb (SG passport)	64	~45	70%
7-day, $1200, Feb (Budget, SG)	64	~28	44%
7-day, $3000, Jul (Monsoon)	64	~38	59%
7-day, $3000 (US/LAX passport)	64	~52	81%
7-day, $3000 (India/BLR passport)	64	~32	50%

Key insight: The survivor count is lowest for tight budgets (28–38 survivors), short trips with proximity caps (~36), and monsoon dates (~38). However, the core issue was not just the count, it was that the filtering rules (like the 4-hour commute) were structurally misaligned with how people travel in specific regions.

Diagnosing the True Problem: Structure, Not Just Breadth

We evaluated the limitation across three dimensions:

Dimension	Evidence	Severity
Breadth (Number of destinations)	64 total; 40–50 survive filtering. A 40-candidate pool is large enough for Claude to rank, but insufficient for comprehensive discovery.	Medium
Depth (Information per destination)	Missing destination-pair information (distance, travel times, route feasibility).	High
Structure (Relationships/attributes)	No multi-city solver or planning logic. Corridors are labels, not computational graphs.	High

Conclusion: This is primarily a DEPTH + STRUCTURE problem, and secondarily a BREADTH problem. Adding more destinations (breadth) would not fix multi-city planning without distance data (depth) and a sequencing solver (structure).

The Proposed Solution: A Multi-Paradigm Architecture

The fix is to build a multi-paradigm architecture with 240–270 destinations across 4 distinct travel paradigms, each with its own rule-set:

Paradigm	Destinations	Rule (Max Commute)	Pattern
Efficient Rail	60–70	4h max	City-chaining (5+ cities in 12 days)
Island-Hopping	50–60	3.5h max (door-to-door)	Island sequences
Self-Drive Scenic	40–50	6–8h (drive is attraction)	Road-trip routes
Overland Explorer	20–30	8–16h (journey is destination)	Expedition circuits

To enforce this, a new transport layer was defined (ParadigmProfile), which includes:

• max_commute_hours
• travel_day_accounting (whether a drive counts as a "partial" or "full" day)
• solver_rules (e.g., allowing iconic routes to exceed the max commute if justified).

Validation: The Solver Works

The core solver logic has been smoke-tested and validated:

• 11/11 test scenarios passed (covering each paradigm, mixed-paradigm, and edge cases).
• A previously broken 6-city China route (which had 0 feasible routes due to one-directional transport edges) now yields 4 feasible routes after fixing graph symmetry.
• The Beijing-Xi'an exception route (11.5h) now validates correctly under the iconic-route allowance.
• Solver latency was observed at <50ms during the smoke test, well within the production target (<100ms).

Architectural Decision: Structure First

When evaluating how to expand, we compared three architectural options:

Dimension	Curated (Breadth)	Dynamic Retrieval	Hybrid (Structure + Solver)
Multi-city feasibility	No (no routing data)	No (no routing data)	Yes (with distance layer + solver)
Engineering complexity	Low	Medium	Medium–High

Final Recommendation: Proceed with the multi-paradigm architecture and sequencing solver.

Rationale:

1. Multi-city becomes real (the current system guesses; the new system validates).
2. It covers our identified market gaps (SG, USA, global explorers).
3. The scope is tight (240–270 destinations is 3x current size, not 10x).
4. The ROI is clear: each layer (paradigm, transport, solver) unlocks new recommendation patterns.

7. The Breadth–Depth Trade-off

Expanding breadth introduces its own trade-offs. More destinations can provide more possibilities, but can also introduce:

• Lower-quality or incomplete destination data
• More irrelevant candidates
• Larger candidate sets
• More context for the model to process
• Higher latency or cost
• More maintenance

So the goal isn't:

"Support as many destinations as possible."

It is:

"Provide enough high-quality possibilities for the system to consistently find genuinely relevant recommendations."

That means breadth has to grow alongside the quality and structure of the underlying destination data.

8. How We'll Know Whether Breadth Actually Improved the Product

The number of destinations in our database is useful as an implementation metric, but it is not the outcome we ultimately care about.

I want to measure whether expanding the recommendation universe actually improves the user experience.

Breadth

• How many viable candidates exist for each user scenario?
• How often does the candidate pool become too small?
• How diverse are the destinations being recommended?
• How often are the same destinations repeatedly surfaced?

Recommendation quality

• Do recommendations satisfy the user's constraints?
• Do they align with the user's preferences?
• Do users save them?
• Do users regenerate because the recommendations weren't useful?

Discovery

One particularly useful signal will be whether we can introduce new but relevant destinations without sacrificing recommendation quality.

The success condition is therefore not:

"We increased the database from 60 to 500 destinations."

It is:

"Users are now seeing a broader range of destinations that are still genuinely relevant to their specific trip."

9. What I Learned

This investigation changed how I think about personalisation in AI products.

Personalisation isn't only about understanding the user more deeply. It is also about having enough relevant possibilities to act on that understanding.

We had been improving the depth of our personalisation by capturing more of the user's constraints. The next bottleneck was breadth: expanding the universe of possibilities the system could consider.

This also highlighted an important principle for AI product building:

When an AI system repeatedly produces similar outputs, the problem may not always be the model or the prompt. Sometimes the model's search space is the constraint.

As we are building an actual technical solution, we have also learned that:

• Data size ≠ data power. A well-structured 100-destination dataset is more useful than an unstructured 1000-destination dataset. The system's inability to plan multi-city trips was not solved by having more cities; it required a routing layer.
• AI products need deterministic layers underneath. Ranking (what Claude does) works best when constrained by planning logic (what a deterministic solver does).

For Exploren, expanding that search space is an important step towards the longer-term vision: moving from a system that can generate a reasonable trip to one that can consistently surface highly relevant possibilities users would genuinely want to explore and book.