Supplier Sampling Plan

The project

Our project aimed to support Food Business Operators and food safety auditors in making more efficient, risk-informed sampling decisions for recipes and ingredients. Before our project, the client had access to a large food safety dataset, but it was difficult to use this data directly for recipe-level risk assessment. Our goal was to build a platform that connects recipe information with historical food safety data, so that users can identify ingredients, countries of origin, and parameters that may require more attention.

The product is a local full-stack web application. Food Business Operators can register, log in, upload or manually create recipes, and assign recipes to auditors. The backend validates ingredient names, countries of origin, and delivery dates, then calculates ingredient-level and recipe-level risk scores based on historical food safety data stored in a PostgreSQL database. Auditors can review assigned recipes, inspect risk scores and risk factors, flag recipes for further review, and use the analysis view to support testing decisions.

The solution gives the client a working MVP for ingredient-based chemical-risk monitoring. It helps make historical CHEFS data more usable for practical sampling decisions, reduces manual interpretation work, and provides a clearer workflow between FBO users and auditors. Although the system is not a production-hosted service, it demonstrates how the client’s risk-assessment process could be supported by a structured digital tool.

Turning a complex food safety database into a usable risk-assessment workflow was the core challenge of our project.

The customer

Our client was Klaas Schouten from AuditLab, with the project supported in the context of Ludev. The client was interested in exploring how historical food safety data could be used to support ingredient-based risk assessment and sampling decisions for food products.

Communication with the client took place through meetings, emails, feedback moments, and project demonstrations. During the project, the client provided domain knowledge, clarified expectations, reviewed our progress, and gave feedback on the product scope and handover requirements. Communication was sometimes challenging because the project involved both technical development and domain-specific food safety interpretation, but regular discussion helped us refine the MVP scope and focus on the most relevant workflows for FBO users and auditors.

Working with the client showed us that a technically working system also needs clear explanations, realistic scope, and careful handover.

The team

Our team worked with a Scrum-inspired process and divided the work across frontend, backend, database, risk calculation, testing, documentation, and client communication. Team members took responsibility for different parts of the system, including the user interface, recipe upload and validation workflow, database setup, risk aggregation, API endpoints, testing, and final handover materials.

The work was collaborative because most features depended on multiple layers of the application. For example, recipe upload required frontend components, backend validation, database access, and risk calculation logic to work together. We used meetings, shared documents, GitHub, and regular internal communication to coordinate progress and resolve integration issues.

One of the main challenges was turning a large and complex food safety dataset into a usable MVP within the limited course timeframe. Another challenge was keeping the project scope realistic while still delivering something useful for the client. We are most proud that we delivered a working full-stack platform with role-based workflows, recipe import, validation, risk scoring, auditor review features, automated tests, and handover documentation.

The technologies

Languages:

• Python: backend logic, API routes, validation, import pipeline, and risk calculation.
• TypeScript and JavaScript: frontend application logic.
• HTML and CSS: frontend structure and styling.
• SQL: database queries and PostgreSQL data access.

Core frameworks and tools:

• FastAPI: backend web framework and API implementation.
• React and Vite: frontend application and development server.
• PostgreSQL: storage for application data, reference tables, and aggregated food safety data.
• pytest: automated backend testing.
• Ruff: Python linting.
• ESLint and TypeScript checking: frontend code quality and type checking.

Infrastructure and setup:

• GitHub Actions: CI workflow for backend linting/testing and frontend linting/type checking/build verification.
• Tailscale: secure access to the project database server during local setup.
• Local deployment setup: the application is run locally with a Python backend server and a Node/Vite frontend development server.