Turning taste expertise into usable software
TasteIndex helps webshops recommend products that suit their customers’ tastes. We developed its prototype into a configurable platform and built an AI recipe rater. Throughout the project, we kept returning to one question: how do you make specialist knowledge useful without adding manual work for every new customer or recipe?
A taste platform with gradual webshop integration, independent administration and automated recipe ratings.
- Industry
- E-commerce
- Location
- Rotterdam
Team
The challenge
One taste concept, different webshops
TasteIndex had a developed approach to taste and a working prototype. A visual questionnaire allowed consumers to map their preferences, giving webshops information they could use to recommend suitable products. What was missing was a development team to turn that into a product for different customers.
From the outset, the application needed to be stable, scalable and configurable. Each webshop needed its own branding, but customers had different technical capabilities. One could place a test on a page; another wanted to rank its entire catalogue by individual preferences.
When technology catches up with reality
TasteIndex started with wine. To assign taste coordinates to a wine, the company had it tasted by an expert. More tasters can share that workload. But TasteIndex had bigger ambitions. Beyond other drinks such as coffee and soft drinks, it wanted to rate food and even entire meals. Moving into recipes changed the challenge: before anyone can assess a dish, someone has to buy the ingredients and prepare it.
Every new data point would therefore require a complete meal. For a large recipe collection, shopping, cooking and tasting would add time and cost with each assessment. Alongside the consumer software, we needed a way to assess recipes without preparing every dish. Read on to see how we approached this.
Our approach
Start small and build from there
We began with what a webshop could actually integrate. The taste test can be embedded as an iframe: a separate window within the page, with its own styling. After completing the test, visitors can be directed to a landing page for a taste category. An initial integration does not yet need to support individual product ranking.
The integration can then grow. For individual recommendations, the webshop calls the TasteIndex API and incorporates the matches into its product listings. That requires more technical capability on the customer’s side. Developing the integration in stages gives customers something useful before every option is connected.
Routine administration should not need a developer
A configurable platform also needs a way to manage its settings. We proposed building an Admin interface so TasteIndex would not need a developer for every little change. The interface includes settings for colours, fonts, result views and landing pages.
That freedom also has a downside. The more settings need configuring for each customer, the more work it takes to bring a new customer on board. Choosing defaults from the start means settings only need changing where a customer has a specific requirement.
An embed is a starting point
The webshop integration also involves specific trade-offs. An iframe keeps the taste test’s styling separate from its host website. A webshop stylesheet cannot inadvertently change the test’s buttons or fonts. TasteIndex can still adapt the appearance to each customer through its own settings.
That separation makes the initial connection more manageable, but it does not remove all integration work. Even embedding an iframe proved difficult for some customers. Individual product ranking also requires the webshop to call the API and process the results dynamically. Both the simple test and the deeper integration therefore have a place in the product.
What this delivers
TasteIndex has an embeddable taste test, an API for personal product matches and an interface for managing everyday settings. The company can handle administration that would otherwise fall to developers. For recipes, we took things a step further.
Technology that makes the difference
Assessing recipes with documented taste expertise
During a joint brainstorming day, we explored ways to assess recipes with TasteIndex. A language model offered a way to apply knowledge about ingredients and cooking to recipe text. We developed a pipeline that combines each recipe with taste guides and reference ratings.
This took substantial research and development. We reviewed the results as we worked and adjusted the instructions when the model went off track. Knowledge of food and cooking within the team helped us recognise those mistakes. The quality of the approach also depended on our ability to assess the model’s reasoning.
Explain first, then score
The AI Rater estimates three properties: astringency (the drying or puckering sensation in the mouth), mouthfill (such as body and creaminess) and flavour intensity. Both ingredients and preparation steps go into the assessment. A list of ingredients alone does not explain how they are prepared together.
For each dimension, the prompt asks for a justification before assigning a score between 0 and 100. The detailed analysis also identifies the ingredients and techniques that influence each score. This lets us review how the model arrived at its estimate. A convincing explanation does not by itself prove that a taste assessment is correct; reviewing the substance of the results remained necessary during development.
The pipeline is written in Python and calls the language model through OpenRouter. The fixed taste reference material is submitted with caching enabled, allowing it to be reused across assessments to reduce costs. Requests are handled independently, so large numbers of recipes can be processed in parallel.
Continuity and ongoing development
Infrastructure you can read in Git
A platform with a backend, administration interface and multiple integrations needs to be understandable and manageable by others. We therefore define the infrastructure as code. TasteIndex uses Terraform to describe its AWS infrastructure, with the configuration versioned in Git.
This makes the intended setup readable and allows changes to be reviewed and deployed as code. It reduces reliance on someone remembering settings they once changed manually in a cloud interface. Application code and infrastructure follow the same approach to recording changes.
Reducing dependencies on customer infrastructure
Problems with certificates and DNS managed by customers prompted a move towards running more of the platform on TasteIndex’s own domains. This reduces how often a change depends on a customer’s technical setup. Customer domains are still configured too; how much can be managed directly depends on the integration.
The infrastructure also includes Sentry error reporting and daily product feed jobs. These provisions are part of the technical setup. As development continues, the behaviour of the integrations and the data they supply still need attention.
Give the data model attention early
The platform began with wine and later gained a generic model for products and ratings. That makes the software usable across different product categories. These decisions also have lasting effects: application code can be changed, but altering the structure of existing data requires extra care.
We therefore pay close attention to the data model, strong typing and explanations in the code. Together with infrastructure defined as code, this makes the software easier to hand over and adapt as needs change. The next step might be a new integration, better defaults or customer self-service. We decide which step makes sense based on how the product is used and in consultation with TasteIndex.
Want to turn specialist knowledge into software your customers can use and your team can manage? Talk to us about your project.
What this case shows
Start with an achievable integration. A taste test linked to category pages can be useful before a webshop supports individual product ranking.
AI still needs domain expertise. Recipe ratings require documented taste knowledge and people who can recognise when a model’s reasoning goes off track.
Flexibility needs careful administration. Configuration options create setup work. Consider defaults, independent administration and scalable infrastructure too.