How to Add a Recommendation System to Your Product (Lessons Learned from Two Projects)

When a platform grows from a few dozen listings to several hundred—whether they are professionals, events, content, or products—people often end up seeing the same ones over and over again, while much of what is available goes undiscovered. At that point, the idea of using AI for recommendations usually comes up, along with the usual questions: how much will it cost, how much data do you need, and is it actually worth it?

At Softspring, we have built two custom recommendation systems with very different requirements. One helps the coordinator of a psychology platform identify which psychologists are the best match for each patient. The other recommends destinations, events, and activities to members of a digital nomad community based on what they say they are looking for and the places they have visited. The underlying problem is similar, but the available data was very different, and that shaped almost every decision we made.

What decision do you want to help people make? Matching someone with the professional who will support them for months is an important decision, made once and with a lot at stake. Choosing your next destination or which activity to join is a lighter decision that happens frequently. Each case calls for a different system and a different level of human involvement.

How will you know whether the recommendation was successful? Without an answer to that question, it is very difficult to improve the system, and a click is rarely a useful measure. In the first case, success might mean that the patient continues after the first session. In the second, it might mean that the person ends up booking or signing up for something that was recommended to them. 

How large is your catalog, and how much activity do you have? With 40 professionals and a search engine with good filters (specialty, language, availability, price), the problem may already be solved. A recommendation system starts to pay off when the catalog is too large for anyone to review manually, or when the choice depends on nuances that cannot be captured in a dropdown, such as explaining in your own words why you are looking for help or what kind of trip you feel like taking.

If, after considering all of this, you realize that improving your filters and search is enough, it is better to know that from the start. It is cheaper, requires less maintenance, and no one has to justify why the system recommended one thing over another.

• Content-based filtering: recommends items similar to what a person says they want or has already used by comparing their characteristics.
• Collaborative filtering: recommends things that other people with similar behavior liked.

The first works from day one if the catalog is well described. The second requires a substantial amount of historical data. Many production systems combine the two and adjust the weight of each as they accumulate more data. The two projects we discuss here rely mainly on the first approach, because neither had enough historical data for the second.

 Language models have significantly changed content-based filtering. With embeddings (representing text as a list of numbers so that meanings can be compared rather than exact words), you can match “I want somewhere quiet with a good internet connection and close to the sea” with a destination whose description mentions coves, coworking spaces, and the low season, even if they do not share a single word. It is the same technique we use in RAG systems for company documentation.

La Psicóloga en Casa is an online psychology platform. When someone signs up, they describe the reason they are seeking help in their own words, and the platform has to match them with one of the available psychologists. 

What data is available? Almost no behavioral data. Each patient arrives with no previous history, and the decision can have a significant impact on them. Collaborative filtering did not make sense here: there are not enough “patients like you who chose this psychologist,” and even if there were, that is not a criterion you would want to use in mental healthcare. 

How is the decision made? A language model (Google Gemini) reads the reason for seeking help and matches it against each psychologist’s areas of expertise and availability. It then produces a short list of candidates who are a good fit for the case and are also available to take it on. 

What role does the human play? The patient never sees the recommendation. It is sent to the platform coordinator, who reviews the suggestions and manually chooses which psychologist to assign to the case. The AI saves her from having to read each patient’s reason for seeking help and compare it against the entire team, while the final decision remains with someone who knows the professionals and can take into account factors that do not appear in any profile. 

We designed it this way from the outset. In healthcare, a poor match can have a significant impact on the patient, and having a knowledgeable person review every suggestion is what allows AI to be used confidently in this part of the process.

The second case is a platform for a digital nomad community, in its initial 2025 version. Here, decisions are smaller and more frequent—where to go next, what to do there, which event to join—and the catalog grows through contributions from the community itself.

What data is available? Event, destination, and activity listings, each user's conversations with the platform via chat, and their history within the community—that is, which events they have attended and which destinations they have visited. In conversations, people explain what they are looking for, what they liked, and what they did not, in far more detail than they would by ticking boxes on a form. Their history adds information they may not have explicitly shared. 

How is the decision made? We generate embeddings for events, destinations, and activities, as well as for the user's conversations. When someone searches for something, the system combines all of this to find destinations and suggestions that match what they are looking for, even if they have never mentioned them. If someone has talked about surfing, working in the mornings, and avoiding big cities, the system can suggest a destination they did not know about that meets all those criteria. 

How does it learn from each person? As a digital nomad attends events and visits destinations, that history also becomes part of the search. For example, the system avoids suggesting places they have already visited, while their past choices help refine the types of activities and destinations that are likely to suit them. 

This approach works from the very first conversation and improves with use, so there was no need to wait months for the community to build up enough activity before the recommendations became useful.

Cold start is what happens when a recommendation system needs behavioral data but none is available yet—because the platform is new, the user has just joined, or the item was only published today. It happens in almost every project, so it is worth planning for it from the outset.

• Start with rules and content. A first version based on clear rules (availability, specialty, dates) and content similarity can already be useful and easy to explain. 
• Let people explain what they are looking for. A reason for seeking help or a conversation provides more information than a long form that many people never finish. With language models, that free-form text can be put to use from the very first message.
• Use popularity carefully. The most viewed items can be a good starting point, but relying on popularity alone means the system will keep recommending the same things and new items may never get seen.
• Collect signals from day one, even if you are not using them yet. If you want to add collaborative filtering later, you will need months of historical data.

On the digital nomad platform, the part that took the most iteration was combining chat conversations with recommendations. Not everything in a conversation is a search: there is casual chat, offhand comments, and questions that have nothing to do with choosing what to do. If all of that is treated the same way, it adds noise to the recommendations.

We also found that the system would sometimes suggest events that might interest someone but were in a destination that was not a good fit for them. Solving both problems involved a lot of back and forth to adjust how much weight each factor had in the results: the conversation, the user's history, the destination, and the event itself. Each change in weighting could improve some cases while making others worse, and that is difficult to spot when reviewing cases one by one.  

If you do not measure it, over time no one really knows why the system recommends what it recommends, and making changes becomes much harder.

An outcome metric, defined before launch. This should come from thinking about how you will know whether a recommendation was successful: continuing after the first session, or bookings and sign-ups resulting from a recommendation. Clicks are useful for debugging, but they do not tell you whether the recommendation was actually good. 

Something to compare against. It is worth measuring the system against what was there before, or against something simple such as ranking by popularity. If the recommendation system does not clearly improve on that baseline, it probably does not justify the additional complexity. When there is enough volume, an A/B test is the most reliable way to find out. 

A test set with expected results. This involves collecting a series of real or representative cases—a conversation, a user history, a search—and documenting what the system should recommend in each one. Every time you change a weight, a prompt, or the model, you run the entire test set and see which cases improve and which get worse. For adjustments like those we made to the digital nomad platform, this is one of the most useful tools available, because it lets you compare models and changes using data rather than impressions. Tools such as Langfuse are particularly useful here: they store the trace of each recommendation—what went in, what the model did, and what came out—allow you to maintain these test sets, and make it possible to compare different versions. It is also open source and can be hosted on your own infrastructure, which is worth considering when working with sensitive data. 

Human review. Someone who understands the business should periodically review a sample of real recommendations, because some errors do not show up in aggregate metrics but are immediately obvious to a person. When someone validates every suggestion, as the coordinator does at La Psicóloga en Casa, their decisions can also be used as a measurement signal: whenever they choose someone outside the suggested list, it is worth looking into why.

A recommendation that can be explained is easier to maintain. For a user, a line such as “because you’re looking for somewhere quiet to work and you’re interested in surfing” builds trust and gives them a chance to correct the system. For a coordinator, knowing why each psychologist has been suggested helps them make decisions faster and spot when a recommendation does not make sense. For the technical team, being able to see what data was used for each recommendation makes it easier to identify errors and answer questions when someone wants to know why something unexpected was suggested.

That is why we prefer systems that can be explained and measured, even if they are slightly less sophisticated. For us, that is what responsible, measurable AI looks like: a system the client understands, can audit, and can improve without depending on us for every question.

Every recommendation system works with personal data, so before getting started, it is worth documenting what is stored, where it is processed, and how long it is retained.

For catalog information and usage data, it is usually enough to provide clear information, store only what will actually be used, and allow people to disable personalization. Chat conversations require more care, because people tend to share more in them than they would in a form. 

When health data is involved, the requirements are much stricter. The GDPR considers health data a special category of personal data, which means having a stronger legal basis, processing only what is strictly necessary, and carefully managing every step the data goes through. If a patient's text is sent to an external language model, you need to use a version that provides appropriate contractual safeguards. In our projects, we use the paid enterprise version of Gemini, which is covered by Google Cloud's data processing agreement with Standard Contractual Clauses, and where data is not used to train models or reviewed by humans. 

The region where data is processed is another decision worth making early on. If your users are in Europe, processing their data in Europe makes things much simpler when dealing with both your legal team and your users, and it is easier to configure from the start than to change later.  

A basic recommendation system that sends a small amount of data to a language model and receives the response in a structured format can cost around €2,000–€3,000. If you need to generate embeddings and build something similar to a RAG system, the project moves to a different scale: you need to add a vector database, generate embeddings for the catalog and for the information provided by each user, run searches against them, and integrate something like Langfuse to ensure full traceability. In that case, the minimum is around €10,000.

In our experience, the algorithm itself accounts for only a small part of the cost. Most of the work goes into preparing the catalog so that items can be compared, properly capturing user signals, setting up measurement, and fine-tuning the system during the first few weeks of real-world use. We have another article on where budgets tend to go off track in custom projects, explaining why software development projects go over budget.

We would start by writing down, in a single sentence, what decision you want to make easier, who ultimately makes that decision, and how you will know whether the outcome was successful. That alone should give you a good idea of whether you need a recommendation system, better filters, or a combination of the two.

If your platform has more content than your users are able to discover, tell us about it and we’ll take a look.