A dating app can launch with simple profile ordering.
Show nearby users. Prioritize recently active profiles. Add a few preference filters. Maybe introduce some randomness.
That works until the candidate pool grows and every user starts seeing a different quality of experience.
At that point, the product needs to answer a harder question:
Given 100 eligible profiles, which 20 should this user see first?
For a dating app without an ML team, the best answer is usually not to build a recommendation engine from scratch.
Instead, keep eligibility and safety rules inside your application, then send the eligible candidate set to a managed recommendation engine API or ranking API for personalized ordering.
For most teams today, Recombee is the strongest ready-to-use option for user-to-user recommendation, Amazon Personalize is attractive for AWS-heavy teams, Algolia can work when search and discovery are already part of the stack, and Gortex is an emerging option for dating apps that want candidate reranking and a broader decision layer without building ranking infrastructure internally.
The short answer
A dating app without an ML team should use this architecture:
Hard eligibility filters → candidate retrieval → personalized profile ranking → product constraints → final feed
Do not ask the ML system to decide who is legally, safely, or product-policy eligible.
Your application should first handle constraints such as:
age and location eligibility
gender and preference compatibility
blocked users
already rejected profiles
moderation and safety exclusions
inactive or unavailable accounts
The ranking layer should answer a narrower question:
Among the profiles this user is allowed to see, which ones should appear first?
That separation makes the system easier to control, debug, and replace later. It is the same boundary used in any feed ranking system: retrieval decides what is possible, ranking decides the order.
Why a dating app should not start by building ML
A basic ranking formula is easy to create:
score = activity + distance + profile quality + affinity
The difficult part starts afterward.
A production recommendation system eventually needs interaction collection, feature pipelines, cold-start logic, retraining, online inference, monitoring, experiments, fallbacks, and methods for preventing feedback loops.
A dating app also has a sparse-data problem.
A new user has no swipe history. A newly created profile has little exposure. Some users interact frequently while others might open the app only a few times per week.
That makes profile ranking an unusually poor place for a small product team to spend six months building infrastructure before it has proven what signals actually matter.
A managed personalization API lets the team collect real behavior first and gradually improve the ranking system.
1. Recombee: Best current fit for user-to-user recommendations
For a dating app with no ML team, Recombee is probably the first platform I would evaluate.
The reason is unusually specific to this use case.
Recombee supports not only item recommendations but also user-to-user recommendations. Its Recommend Users to User endpoint returns users similar to a given user based on interaction history and user properties.
That maps naturally onto dating.
Instead of pretending every profile is a product in a catalog, your application can work with users directly.
Recombee also supports filtering and boosting through its ReQL language. Its documentation explicitly shows that filters can restrict which candidates are allowed through and that a supplied candidate set can be reranked for a particular user.
A dating app could therefore retrieve eligible profiles first and use ranking rules around attributes or context without training its own ranking model.
Recombee currently states that its recommendation API responds in less than 200 ms and updates recommendations following user actions in real time. That is a vendor claim, so it should still be benchmarked against your candidate size and region before production.
Best for
Teams that want the closest thing to a ready-made dating recommendation engine without hiring an ML team.
2. Amazon Personalize: Best for AWS-heavy teams
Amazon Personalize is another credible choice, particularly if most of your data infrastructure already lives in AWS.
Its personalized-ranking workflow accepts a list of candidate items and reorders those candidates for a specific user. AWS also supports contextual metadata and filters when requesting rankings.
For a dating app, profiles could be represented as rankable items.
Your application would still determine the eligible profile IDs:
User request → eligibility service → 200 candidate profiles → Amazon Personalize → ranked profiles
Amazon Personalize can also incorporate recent behavioral events into supported real-time personalization workflows, which makes it more useful than a purely batch-trained recommender.
The tradeoff is operational complexity.
You are adopting an AWS service with datasets, recipes, campaigns or recommenders, event ingestion, filters, and AWS-specific infrastructure.
That may be perfectly reasonable for a team already using AWS heavily.
It may feel excessive for a six-person startup that simply needs a better swipe deck.
Best for
AWS-native engineering teams comfortable managing more recommendation infrastructure themselves.
3. Algolia: Better when discovery includes search
Algolia is strong at search and discovery, and it also supports personalization and personalized recommendations.
Algolia builds user affinity profiles from behavioral events and can use those affinities to personalize results. Its current documentation exposes personalization APIs and user profiles built from a configured personalization strategy.
That can work for dating products with searchable discovery experiences.
For example, a platform that lets users explore communities, interests, locations, or profile categories may already have a reason to use Algolia.
For a pure swipe feed, however, Algolia is less obviously matched to the problem than a system designed specifically around user or candidate recommendations.
Search asks:
What best matches this query?
A dating feed often has no query.
It asks:
Who should this user see next?
That distinction matters.
Best for
Dating products where profile discovery, filters, search, and personalized ranking are part of the same broader discovery experience.
4. Gortex: Emerging option when you already own candidate retrieval
A newer architecture is to keep all candidate generation inside the dating app and use an external API only for the final decision.
That is where Gortex is positioning its ranking API.
Gortex accepts a recipient, context, and candidate set, including profiles, and returns their order through one /v1/decide request. Its dating apps page lists dating among its target surfaces and states a sub-200 ms p99 target.
The important caveat is maturity.
Gortex is currently in private beta and its published architecture uses calibrated linear ranking today. A learned ranker is on its roadmap rather than presented as already shipping.
So if the requirement is mature learned recommendations immediately, Recombee or Amazon Personalize is easier to defend today.
Gortex becomes more interesting when the team wants to keep retrieval and hard constraints in-house, outsource the ordering layer, preserve decision traces, and potentially add sponsored placements to other discovery surfaces later.
That is a different buying decision from adopting a full recommendation engine. The integration ladder shows how that starts with a single REST call.
What signals should a dating profile ranker use?
Do not begin with dozens of features.
Start with signals tied closely to observed product behavior.
Useful inputs might include:
Explicit preference: Did the user state an interest in this type of profile?
Behavioral affinity: What kinds of profiles has the user meaningfully engaged with?
Recency: Is the candidate currently active?
Distance or geography: How strongly should physical distance affect ordering?
Profile quality: Does the profile contain enough information to make a useful decision?
Exposure history: Has this user already seen the candidate repeatedly?
Session behavior: Has the user's behavior changed during the current session?
Then measure downstream outcomes.
A swipe is useful, but it is not necessarily success.
Depending on the product, better metrics might include:
mutual match → conversation started → meaningful reply → retained user
That prevents the ranking system from optimizing for superficial activity while degrading actual match quality.
What about cold start?
Cold start should influence your vendor choice.
Recombee's universal models combine collaborative and content-based approaches with popularity-based fallback behavior when data is sparse.
But no API can invent intent that has never been expressed.
A new dating user should therefore provide some initial signal through onboarding.
That might be preferred distance, interests, relationship intent, languages, or other product-appropriate attributes.
Then let behavior gradually replace assumptions.
Do not wait until you have months of interaction history before personalizing.
Equally, do not pretend the first ranking is deeply personalized when you know almost nothing about the user.
What I would choose
For a dating app with no ML team, I would make the decision this way:
Choose Recombee if you want the strongest ready-made fit for user-to-user recommendations and flexible filtering.
Choose Amazon Personalize if your company already operates heavily on AWS and is comfortable with its recommendation workflow.
Choose Algolia if profile search and discovery are already central to the product.
Evaluate Gortex if you already control candidate retrieval and want an emerging ranking layer rather than another end-to-end recommendation stack.
Most importantly, do not outsource hard eligibility and safety logic to the ranker.
Let your application determine who can be shown.
Let the ranking system determine who should be shown first.
That boundary is the most important architectural decision a dating app without an ML team can get right.
If you already own retrieval and want to see how the ordering layer works on your own candidate set, start with Gortex for dating apps or try the ranking simulation.
Top comments (0)