Flexible configuration
Rikolto configures per organisation which departments, meals and components are measured. That works for residential care centres, hotels and everything in between.
FoodWIN
From paper forms and Excel to real-time insight into food waste
Client
Rikolto
Services
Web application, data platform, UX design, cloud architecture
Sector
Sustainability / food systems / NGO
Timeline
~5 months (exploration to first release)
Status
In testing
Tech stack
Phoenix (Elixir), React, TypeScript, TanStack Router & Query, PostgreSQL, shadcn/ui, Tailwind CSS
The question
Six in ten large-scale kitchens in Belgium waste more food than they think. The problem is not unwillingness. It is invisibility. Kitchen managers juggle dozens of tasks at once, work with changing teams and rarely have time to stop and think about what exactly ends up in the waste container.
Rikolto, an international organisation working on sustainable food systems, had taken over FoodWin a year earlier, a Belgian initiative around food waste. The takeover came with a measurement method: kitchens go through a journey from baseline measurement to impact measurement, with a strategic analysis and an action plan in between. The process works. The tooling did not.
Measurements happened on paper. Forms per day, per meal, per department. Afterwards those figures were typed into Excel by hand. Weeks, sometimes months, sat between measurement and analysis. Meanwhile the kitchen team lost the motivation to keep measuring. And Rikolto lacked the speed to adjust course along the way.
Rikolto was looking for a partner who could carry the whole journey: from domain analysis to a working platform. They came to us through a referral. There were no designs or specs. There was a clear need and a team that knew the problem inside out.
Approach
A domain that does not fit in a spreadsheet
The first weeks were pure exploration. We visited a residential care centre, talked to kitchen managers and researchers, and mapped the entire measurement process. What looked like a simple data-entry tool at first glance quickly turned out to be a lot more complex.
An organisation has departments, and every department serves meals. Those meals consist of components: proteins, starch, vegetables, composite dishes. Per component you measure in bulk or per standard portion. Leftovers come from three streams: kitchen, buffet or plate. All of that has to be logged per day, per meal moment, per department.
On top of those daily measurements sits a journey structure: baseline measurement, action plan, impact measurement. Costs and CO2 footprint are tracked per component, so the impact becomes visible financially and ecologically too.
The data model counts more than fifteen entities with complex relationships. That is not the kind of problem you solve with a form builder or a BaaS platform. We deliberately chose Phoenix with Elixir on the backend and React with TypeScript on the frontend. That combination gave us the control over the domain model we needed, and the flexibility to iterate quickly on the UI.
Two worlds, one interface
The project had a built-in tension from the start. Rikolto wants rich, granular data. Comparisons per component, per stream, per department. Charts that reveal patterns across months. Exports to Power BI for deeper analysis.
The kitchen worker wants something that works between two shifts. Enter it quickly, not too much thinking, not too much clicking. In an environment with staff shortages, high turnover and never enough time.
Those two worlds had to come together in the same tool. They do not bite each other, they reinforce each other. The easier the data entry, the more consistent the measurements. And the more consistent the measurements, the better the data for Rikolto. Usability is not a side issue here. Without good UX you simply do not get reliable data.
We built two entry options. A fast wizard for daily use: pick a date, select a meal, fill in weights. Done. And an expert mode for those who want to go deeper: per stream, per component, with notes and photos. Both modes write to the same data structure, so the analysis is always consistent.
From paper to screen and back
Not every kitchen works digitally. In many facilities, weighing still happens with a kitchen scale and a notepad. That is the reality, and we did not want to design around it.
The platform generates printable measurement forms based on the journey configuration, with the right departments, meals and components already filled in. After weighing, the kitchen team can enter the figures into the platform later. Some teams do it the same evening, others at a fixed moment in the week.
Other kitchens do work digitally on the spot. Phone next to the scale, enter the weight, on to the next measurement. Both workflows are supported. The choice lies with the team on the floor.
When reality corrected the model
Halfway through development we hit a problem we had not foreseen. Meal configurations were originally linked to the journey as a whole. But in practice, not all departments serve the same meals. A residential care centre has a dementia ward with its own menu, a dietary department with different components, and a general department. Hotels run a buffet and à la carte side by side.
The domain model had to change. Meal configurations were linked to specific departments. Dietary streams were added as an attribute. That meant a new database schema, adjusted APIs and an updated UI.
The architecture could take it. Because we had invested in a tight domain model with clear entities and relationships from the start, the change was clean. No workarounds, no technical debt. Reality on the floor corrected our model, and the system could follow without turning everything upside down.
Multi-tenant from day one
Rikolto does not coach one organisation but dozens. The platform had to support multiple organisations from the start, each with their own journeys, configurations and users. A Rikolto administrator sees the full overview. Kitchen managers only see their own organisation, and measurers never get past the measurement screens.
We built a role model with three levels (administrator, champion, measurer) and an invitation system with magic links. No passwords. That simplifies onboarding in a context where not everyone is equally comfortable with digital tools.
The result
The platform is up and running. Rikolto is testing it with the first organisations. Six releases in three months, from basic setup to a working measurement platform.
What's in place:
Detailed measurement logs
Measurement logs down to meal level, via a fast or a detailed interface. Every log contains date, department, meal, component, stream and weight.
Integrated impact measurements
Baseline and impact measurements are built into the journey. Rikolto can measure and report progress directly.
Statistics and data export
Statistics per component, department and stream, with comparisons between measurement periods. Export to CSV and Power BI for further analysis.
Multi-tenant self-service
Multi-tenant architecture, ready for self-service. After initial guidance, organisations can work with it independently.
The multi-tenant setup carries dozens of organisations at once. Through Power BI, Rikolto can run analyses that go beyond what the platform itself shows. And because the data is structured and spans organisations, comparison between kitchens becomes possible, and in time targeted recommendations too.
Do you need a digital product that goes further than a website or app?
Tell us where your organisation wants to go and what's difficult today. We'll think along about a first workable step.
Schedule a call
You'll speak straight away with someone who digs into the actual problem.
Not ready for a conversation yet? Take a look at what we've built