Introduction
In 2024, my partner and I wanted to develop a household management solution to keep track of our inventory, favorite recipes, and macronutrient intake.
We tried existing solutions, but they were too cluttered for our taste. We also wanted something easily customizable - this led to the creation of Leltár (Hungarian for “Inventory”), a prototype food management application.
In this article, I’ll showcase the solution, share the lessons we learned that led us to stop using it after two months, and explore potential improvements for the future.
Model
First things first, we had to come up with an abstraction that would support the necessary calculations while also ensuring a good user experience.
Food
The lowest-level building block is called Food. A Food has a name and nutritional facts, including energy, fat, saturated fat, carbohydrates, sugars, protein, and salt. It can be a standalone food, like a hamburger, or an ingredient used as part of a Recipe (see below).
Each Food can have its own units of measurement to simplify calculations and logging. While nutrition facts are generally provided per 100g of the consumable, we allow predefined weight aliases, such as “bottle” for soda or “bag” for pasta, to make tracking more straightforward.
Recipe
A Recipe consists of one or more ingredient Foods. The nutritional facts are automatically calculated based on the underlying Foods used in the Recipe.
Just like Foods, each Recipe can have its own units of measurement to accommodate different serving sizes or quantities.
Member
A Member (of a household) has a name and optional daily nutrition goal targets. The daily nutrition facts for each member are summarized and displayed on a chart, and an AI-generated summary is provided as feedback based on their daily consumption.
Meal
A Meal consists of a name, start and end times, and is used to assign LogEntrys to specific meals. The meal is automatically selected based on the current time, but Members have the option to override the automatic selection.
LogEntry
Each time a Member eats something, they create a new LogEntry. A LogEntry includes the date, Meal, the Recipe or Food consumed, and a list of Members who participated in the meal. The consumed amount is recorded either in raw grams or using a predefined unit of measurement for each Member.
Container
To determine the actual weight of a consumed meal, one needs to subtract the weight of the empty container. Since this process can be cumbersome, we introduced a Container entity. A Container has a name and a predefined weight, allowing users to select it when logging entries, making the process more convenient.
Activity
Calories can add up quickly without considering any physical Activity a user may have performed. To account for this, a Member can log the energy they burned during activities, which is then subtracted from their daily totals.
In the proof of concept (PoC), Activity data is automatically synced from Strava, making tracking more seamless.
Technology stack
The frontend was built using Svelte, while the backend was implemented with FastAPI, using the following PostgreSQL database:
Pain points
- Manual data entry
- Nutrition facts had to be entered manually, making the application painful to use until the food & recipe database was populated.
- Lack of reliable nutrition data
- Some foods (e.g. fresh vegetables from a local farmer’s market) don’t have nutrition facts on the packaging, requiring users to look up data from external sources, which are sometimes contradictory.
- Measuring every portion
- While weighing portions works well for single-dish meals, it becomes cumbersome for multi-component meals like rice, sauce, and pickles.
- Cooking adjustments
- Measuring everything precisely in advance is difficult since cooking often requires adding small extra amounts of ingredients later on.
Improvement Ideas
- Use OCR to scan nutrition facts
- Nutrition labels in the EU follow a standardized format, making this a viable solution.
- Search in external nutrition databases
- A purpose-built search engine using web scraping could enhance the in-app experience for foods having no nutrition facts available on the packaging
- Introduce a
Householdentity- It would allow multi-user collaboration and could serve as a tenant structure in a multi-tenant B2C SaaS model.
- Track inventory
- Monitor available ingredients and update stock automatically when food is logged.
- Automated shopping list
- Generate a shopping list based on depleted ingredients.
- Custom fields
- Allow users to define custom fields beyond standard nutrition facts to support personalized tracking needs.
Conclusion
Developing and using the application was a fun and insightful experience, but ease of use remained a challenge. Over the two-month experiment, we gained a deeper understanding of our eating habits and we were able to analyze the food we cooked. These learnings will be valuable in the future, making the overall PoC a success.
We also identified several potential improvements, which we may revisit in the future to refine and enhance the solution.