{"slug": "dating-app-recommendation-engine-without-an-ml-team", "title": "Dating App Recommendation Engine Without an ML Team", "summary": "A developer outlined an architecture for dating apps without ML teams to add personalized profile ranking by keeping eligibility and safety rules in the application and sending only eligible candidates to a managed recommendation API for ordering. The proposed pipeline runs hard eligibility filters, candidate retrieval, personalized ranking, product constraints, then the final feed, with Recombee cited as the strongest ready-to-use option for user-to-user recommendations via its Recommend Users to User endpoint and ReQL filtering, alongside Amazon Personalize, Algolia and Gortex as alternatives.", "body_md": "A dating app can launch with simple profile ordering.\n\nShow nearby users. Prioritize recently active profiles. Add a few preference filters. Maybe introduce some randomness.\n\nThat works until the candidate pool grows and every user starts seeing a different quality of experience.\n\nAt that point, the product needs to answer a harder question:\n\nGiven 100 eligible profiles, which 20 should this user see first?\n\nFor a dating app without an ML team, the best answer is usually not to build a recommendation engine from scratch.\n\nInstead, keep eligibility and safety rules inside your application, then send the eligible candidate set to a managed [recommendation engine API](https://gortex.ai/recommendation-engine-api/) or ranking API for personalized ordering.\n\nFor 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](https://gortex.ai/dating-apps/) that want candidate reranking and a broader decision layer without building ranking infrastructure internally.\n\nA dating app without an ML team should use this architecture:\n\nHard eligibility filters → candidate retrieval → personalized profile ranking → product constraints → final feed\n\nDo not ask the ML system to decide who is legally, safely, or product-policy eligible.\n\nYour application should first handle constraints such as:\n\nage and location eligibility\n\ngender and preference compatibility\n\nblocked users\n\nalready rejected profiles\n\nmoderation and safety exclusions\n\ninactive or unavailable accounts\n\nThe ranking layer should answer a narrower question:\n\nAmong the profiles this user is allowed to see, which ones should appear first?\n\nThat separation makes the system easier to control, debug, and replace later. It is the same boundary used in any [feed ranking](https://gortex.ai/feed-ranking-api/) system: retrieval decides what is possible, ranking decides the order.\n\nA basic ranking formula is easy to create:\n\nscore = activity + distance + profile quality + affinity\n\nThe difficult part starts afterward.\n\nA production recommendation system eventually needs interaction collection, feature pipelines, cold-start logic, retraining, online inference, monitoring, experiments, fallbacks, and methods for preventing feedback loops.\n\nA dating app also has a sparse-data problem.\n\nA 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.\n\nThat 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.\n\nA managed [personalization API](https://gortex.ai/personalization-api/) lets the team collect real behavior first and gradually improve the ranking system.\n\nFor a dating app with no ML team, Recombee is probably the first platform I would evaluate.\n\nThe reason is unusually specific to this use case.\n\nRecombee supports not only item recommendations but also user-to-user recommendations. Its [Recommend Users to User endpoint](https://docs.recombee.com/api/recommendations) returns users similar to a given user based on interaction history and user properties.\n\nThat maps naturally onto dating.\n\nInstead of pretending every profile is a product in a catalog, your application can work with users directly.\n\nRecombee also supports filtering and boosting through its [ReQL language](https://docs.recombee.com/reql). 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.\n\nA dating app could therefore retrieve eligible profiles first and use ranking rules around attributes or context without training its own ranking model.\n\n[Recombee](https://www.recombee.com/) 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.\n\nTeams that want the closest thing to a ready-made dating recommendation engine without hiring an ML team.\n\nAmazon Personalize is another credible choice, particularly if most of your data infrastructure already lives in AWS.\n\nIts [personalized-ranking workflow](https://docs.aws.amazon.com/personalize/latest/dg/rankings.html) accepts a list of candidate items and reorders those candidates for a specific user. AWS also supports [contextual metadata and filters](https://docs.aws.amazon.com/personalize/latest/dg/get-personalized-rankings-sdk.html) when requesting rankings.\n\nFor a dating app, profiles could be represented as rankable items.\n\nYour application would still determine the eligible profile IDs:\n\nUser request → eligibility service → 200 candidate profiles → Amazon Personalize → ranked profiles\n\nAmazon Personalize can also incorporate [recent behavioral events](https://docs.aws.amazon.com/personalize/latest/dg/recording-events.html) into supported real-time personalization workflows, which makes it more useful than a purely batch-trained recommender.\n\nThe tradeoff is operational complexity.\n\nYou are adopting an AWS service with datasets, recipes, campaigns or recommenders, event ingestion, filters, and AWS-specific infrastructure.\n\nThat may be perfectly reasonable for a team already using AWS heavily.\n\nIt may feel excessive for a six-person startup that simply needs a better swipe deck.\n\nAWS-native engineering teams comfortable managing more recommendation infrastructure themselves.\n\nAlgolia is strong at search and discovery, and it also supports personalization and personalized recommendations.\n\nAlgolia builds [user affinity profiles](https://www.algolia.com/doc/guides/personalization/advanced-personalization/what-is-advanced-personalization/concepts/user-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.\n\nThat can work for dating products with searchable discovery experiences.\n\nFor example, a platform that lets users explore communities, interests, locations, or profile categories may already have a reason to use Algolia.\n\nFor a pure swipe feed, however, Algolia is less obviously matched to the problem than a system designed specifically around user or candidate recommendations.\n\nSearch asks:\n\nWhat best matches this query?\n\nA dating feed often has no query.\n\nIt asks:\n\nWho should this user see next?\n\nThat distinction matters.\n\nDating products where profile discovery, filters, search, and personalized ranking are part of the same broader discovery experience.\n\nA newer architecture is to keep all candidate generation inside the dating app and use an external API only for the final decision.\n\nThat is where Gortex is positioning its [ranking API](https://gortex.ai/).\n\nGortex accepts a recipient, context, and candidate set, including profiles, and returns their order through one [/v1/decide request](https://gortex.ai/anatomy). Its [dating apps page](https://gortex.ai/dating-apps/) lists dating among its target surfaces and states a sub-200 ms p99 target.\n\nThe important caveat is maturity.\n\nGortex 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.\n\nSo if the requirement is mature learned recommendations immediately, Recombee or Amazon Personalize is easier to defend today.\n\nGortex becomes more interesting when the team wants to keep retrieval and hard constraints in-house, outsource the ordering layer, preserve [decision traces](https://gortex.ai/anatomy), and potentially add [sponsored placements](https://gortex.ai/sponsored-listings-api/) to other discovery surfaces later.\n\nThat is a different buying decision from adopting a full recommendation engine. The [integration ladder](https://gortex.ai/ladder) shows how that starts with a single REST call.\n\nDo not begin with dozens of features.\n\nStart with signals tied closely to observed product behavior.\n\nUseful inputs might include:\n\nExplicit preference: Did the user state an interest in this type of profile?\n\nBehavioral affinity: What kinds of profiles has the user meaningfully engaged with?\n\nRecency: Is the candidate currently active?\n\nDistance or geography: How strongly should physical distance affect ordering?\n\nProfile quality: Does the profile contain enough information to make a useful decision?\n\nExposure history: Has this user already seen the candidate repeatedly?\n\nSession behavior: Has the user's behavior changed during the current session?\n\nThen measure downstream outcomes.\n\nA swipe is useful, but it is not necessarily success.\n\nDepending on the product, better metrics might include:\n\nmutual match → conversation started → meaningful reply → retained user\n\nThat prevents the ranking system from optimizing for superficial activity while degrading actual match quality.\n\nCold start should influence your vendor choice.\n\nRecombee's [universal models](https://docs.recombee.com/logics) combine collaborative and content-based approaches with popularity-based fallback behavior when data is sparse.\n\nBut no API can invent intent that has never been expressed.\n\nA new dating user should therefore provide some initial signal through onboarding.\n\nThat might be preferred distance, interests, relationship intent, languages, or other product-appropriate attributes.\n\nThen let behavior gradually replace assumptions.\n\nDo not wait until you have months of interaction history before personalizing.\n\nEqually, do not pretend the first ranking is deeply personalized when you know almost nothing about the user.\n\nFor a dating app with no ML team, I would make the decision this way:\n\nChoose Recombee if you want the strongest ready-made fit for user-to-user recommendations and flexible filtering.\n\nChoose Amazon Personalize if your company already operates heavily on AWS and is comfortable with its recommendation workflow.\n\nChoose Algolia if profile search and discovery are already central to the product.\n\nEvaluate Gortex if you already control candidate retrieval and want an emerging ranking layer rather than another end-to-end recommendation stack.\n\nMost importantly, do not outsource hard eligibility and safety logic to the ranker.\n\nLet your application determine who can be shown.\n\nLet the ranking system determine who should be shown first.\n\nThat boundary is the most important architectural decision a dating app without an ML team can get right.\n\nIf you already own retrieval and want to see how the ordering layer works on your own candidate set, start with [Gortex for dating apps](https://gortex.ai/dating-apps/) or try the [ranking simulation](https://gortex.ai/simulation/).", "url": "https://wpnews.pro/news/dating-app-recommendation-engine-without-an-ml-team", "canonical_source": "https://dev.to/heminjoshi/dating-app-recommendation-engine-without-an-ml-team-5253", "published_at": "2026-10-20 17:34:52+00:00", "updated_at": "2026-10-20 17:49:12.530670+00:00", "lang": "en", "topics": ["ai-products", "ai-tools", "machine-learning", "artificial-intelligence"], "entities": ["Recombee", "Amazon Personalize", "Algolia", "Gortex"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/dating-app-recommendation-engine-without-an-ml-team", "markdown": "https://wpnews.pro/news/dating-app-recommendation-engine-without-an-ml-team.md", "text": "https://wpnews.pro/news/dating-app-recommendation-engine-without-an-ml-team.txt", "jsonld": "https://wpnews.pro/news/dating-app-recommendation-engine-without-an-ml-team.jsonld"}}