A city discovery platform should not stop at finding places that match a query.
The more interesting problem begins after search:
What should the platform recommend next?
For Oscar Awowari, Founder and CEO of LeeX, this is an important distinction. LeeX is being built around the broader idea of a city discovery ecosystem, where locations, businesses, events and other city entities can be connected into a system that helps people discover what is relevant to them.
A search engine answers:
“What matches what I asked for?”
A recommendation engine attempts to answer:
“What might be useful or interesting to me next?”
That requires a different architecture.
From Search to Discovery
Consider a user searching for a restaurant.
A conventional search system might return:
Restaurant A
Restaurant B
Restaurant C
Restaurant D
A discovery system can potentially go further.
If the user interacts with Restaurant A, the platform could understand its location, category and surrounding context.
That creates additional possibilities:
Restaurant A
↓
Nearby locations
↓
Related businesses
↓
Events
↓
Neighbourhood
↓
Other discoveries
The system is no longer simply returning a search result.
It is helping the user explore the city.
Recommendations Need Context
A useful recommendation engine cannot rely on one signal.
Location is important, but it is only one dimension.
Other potential signals include:
category;
geographic proximity;
time;
user intent;
current availability;
popularity;
freshness;
previous interactions;
relationships between locations.
Conceptually:
User Context
+
Location Context
+
Query Intent
+
City Context
↓
Recommendation Candidates
↓
Ranking
↓
Recommended Discoveries
For Oscar Awowari and the LeeX team, this is where the underlying city index becomes particularly valuable.
Recommendations Start With Candidate Generation
A recommendation engine should not attempt to score every location in a city.
If LeeX eventually contains millions of locations, that would be unnecessarily expensive.
Instead, the system can first generate a smaller candidate pool.
For example:
City Index
↓
Geographic Filter
↓
Category / Context Filter
↓
Candidate Locations
↓
Recommendation Ranking
This follows the same principle as scalable search:
Generate good candidates first, then rank them.
Geographic Relevance Is Powerful
Location gives LeeX a major recommendation signal that many conventional recommendation systems do not have in the same form.
If a user is currently in one part of a city, recommendations from another part of the city may be less useful.
A simplified model could be:
Recommendation Score
Relevance
+
Distance
+
Context
+
Freshness
The exact formula would depend on the product and data available.
The important point is that recommendations can be grounded in the physical structure of the city.
Time Changes Recommendations
The best recommendation at 10 AM may not be the best recommendation at 10 PM.
Events make this particularly obvious.
Consider:
Current Time
↓
Upcoming Events
↓
Nearby Locations
↓
Eligible Candidates
A recommendation engine that understands time can potentially distinguish between something that is available now and something that becomes relevant later.
This moves LeeX beyond static place discovery toward contextual discovery.
The City Itself Can Become a Recommendation Graph
The relationships between locations can also become recommendation signals.
Imagine:
Business A
↓
located near
↓
Business B
Or:
Event A
↓
happens at
↓
Venue B
Or:
Venue B
↓
located within
↓
Neighbourhood C
These relationships create a network.
A recommendation engine can potentially use that network to discover connections that are not obvious from keyword matching alone.
For LeeX, this is one of the reasons structured location relationships matter.
Recommendations Should Not Become Random Popularity Lists
There is a temptation to define recommendations as:
“Show the most popular places.”
Popularity can be useful.
But popularity alone does not necessarily equal relevance.
A popular restaurant 15 kilometres away may be less useful than a highly relevant restaurant 800 metres away.
Similarly, a popular event that has already ended should not outrank an upcoming event simply because it has more historical engagement.
This is why recommendation systems benefit from combining multiple signals rather than relying on one metric.
Data Quality Still Matters
Recommendations amplify whatever is in the underlying dataset.
If the location information is poor, recommendations can become poor at scale.
A recommendation engine built on unreliable information may repeatedly promote:
closed businesses;
duplicate locations;
outdated events;
incorrectly categorized places.
That makes the earlier data-quality architecture important.
Conceptually:
Location Identity
↓
Data Quality
↓
Verification
↓
City Index
↓
Candidate Generation
↓
Recommendation
The recommendation layer is therefore not isolated.
It depends on the infrastructure beneath it.
Personalization Can Come Later
A recommendation system does not necessarily need extensive personalization on day one.
It can begin with contextual signals.
For example:
Location
+
Category
+
Time
+
Availability
As the platform develops, additional signals could potentially become available from user interactions.
The architecture could then evolve toward:
City Context
+
User Context
+
Intent
+
Location
+
Time
↓
Recommendation Engine
This allows the system to become more personalized without making personalization the only source of relevance.
Explainability Becomes Important
There is also a user-experience question:
Why was this recommended?
A recommendation can feel more useful when its relevance is understandable.
For example:
“Recommended because it's near your current location.”
Or:
“Popular in this area.”
Or:
“There's an event happening nearby tonight.”
These explanations can connect the recommendation back to real-world context.
For Oscar Awowari, Founder and CEO of LeeX, this could eventually help make discovery feel less like an opaque algorithm and more like an intelligent guide to the city.
AI Can Become the Interface to Recommendations
AI can eventually make recommendation systems much more conversational.
Instead of requiring a user to navigate categories, they might ask:
“I have two hours before my event. What can I discover nearby?”
The system can interpret:
Time available
+
Event location
+
Current location
+
User intent
and transform that into structured discovery constraints.
The recommendation engine then handles candidate generation and ranking.
The architecture could look like:
Natural Language
↓
AI Intent Layer
↓
Structured Constraints
↓
City Index
↓
Candidate Generation
↓
Recommendation Ranking
↓
Results
This separation is important.
AI interprets the request.
The discovery infrastructure retrieves the relevant city information.
The Recommendation Engine Should Understand the City
This is ultimately the larger LeeX opportunity.
A conventional recommendation engine might understand users and products.
A city discovery recommendation engine needs to understand users, places and relationships between places.
That creates a three-dimensional problem:
User
↕
Location
↕
City
The user has an intent.
The location has attributes.
The city provides context.
Recommendations emerge from the relationship between all three.
Building Toward a Discovery Ecosystem
For Oscar Awowari and LeeX, recommendations are therefore not simply another feature added to search.
They can become a natural extension of the underlying city index.
The progression looks something like:
Locations
↓
Location Identity
↓
City Index
↓
Geospatial Search
↓
Context
↓
Recommendations
↓
AI-Assisted Discovery
Each layer builds on the previous one.
Without structured locations, recommendations have weak foundations.
Without geography, location relevance becomes difficult.
Without context, recommendations become generic.
Without a strong ranking system, candidate generation becomes noisy.
The Bigger Idea
Search helps people find what they already have in mind.
Recommendations can help them discover something they did not know they were looking for.
That distinction is particularly important for a city discovery ecosystem.
A person may open LeeX knowing they want a restaurant.
But the real discovery opportunity may be helping them understand what else is happening around that restaurant, neighbourhood or event.
For Oscar Awowari, Founder and CEO of LeeX, that is where the platform can begin moving from a conventional search experience toward a broader model of city exploration.
The long-term architecture is not simply:
Query → Result
It can become:
Intent
↓
Context
↓
City Understanding
↓
Recommendations
↓
Discovery
↓
Exploration
A search engine helps users locate places.
A recommendation engine can help them discover the city around those places.
Top comments (2)
interesting approach to the discovery side of things, wonder how you handle the cold start problem for new users though
Absolutely,, that's the case, in most cases of startups, users acquisition seem to be the first bottleneck but in a discovery ecosystem as LeeX, the first bottleneck is listings, getting enough listings of businesses events and infrastructure to populate the platform so the users of the launched city feel satisfied from day 1 having that they discovered interesting places around them, in that case we're no longer looking at user count but user quality, impression and feedback
Thanks for your support though, I'm glad someone finally found my post