Throughout the last few years, I have become slowly more health-conscious. I became aware of the importance of having good nutrition, and the many things that it entailed, including the different macronutrients required for staying in good health. As I mostly cooked at home throughout my time in my bachelor’s degree, I simply excluded unhealthy foods from my eating, including limiting the amount of oil I used, as well as cutting back on sugar drastically. However, a part of the student experience was to try out the local restaurants (at least it was for me), and there my diet went. I could’ve just logged what I ate into a calorie tracker app, but in the context of a restaurant, that caused lots of guessing (and second-guessing) and never being sure if I was on the right path to health.
I accepted that as a fact, and lived my life accordingly, and as such I wasn’t able to completely hit my health goals.
As we started the academic year and this assignment was discussed, many ideas were floated around, such as tools to make international compliance on goods easier, but eventually another group member suggested something I had not thought about in a long time: a way to keep track of your macros regardless of who the cook is. With the development of AI, this was a much more attainable goal, and one I was on board with almost immediately, since it resonated with me directly.
As we decided the parts that each member was going to take on, I ended up with governance, failure analysis, and the final recommendations. In the meantime, I gave some assistance on other parts so we could finish the project as a whole before I started on mine, as my part needed a more complete picture of the app to finish. Through this collaboration during development, I saw something interesting happen that I had only ever heard described: scope creep. As we all gave input on how to develop the app, too many features eventually got proposed, and the scope drifted far from our original plan. We eventually decided what stayed and what went. Because all of us were genuinely interested and invested in the project, it became a real joy to iterate on it, and what came out of that process was shaped in interesting ways by the different backgrounds we each brought.
Finally, when it came to my part, it was greatly supported by the hard work and number-crunching done by those working on the parts before mine, which left me to interpret those numbers and build an analysis on top of them. That was easier said than done, since I had to make sure every claim stayed consistent with the final figures, and those figures often changed with the other group members iterating. Fortunately, I was able to work with the team directly on deciding the right numbers, and they readily told me when a figure or an idea changed, which mattered a lot, since the recommendation and the economics shifted alongside those changes. Deciding the failure conditions and risks the app might face also required a high level of understanding of how the app actually worked, step by step, and what could go wrong at each stage, which meant looking closely into the mechanics as well as the relevant laws and concepts attached to it, like data privacy and allergen regulation. I also found it genuinely interesting to work through the conditions the app would face in an agentic future, since it took a lot of second-order thinking to reason through how everything would behave once other players had agents of their own too.
My first real failure in this part was how I approached governance to begin with. I started by giving risks a label, High or Medium, which looked serious and studious but didn’t say who actually fixes and owns each problem, and was quite subjective. I then rebuilt it around five specific failures, each with an owner and a fix.
The future-market part of my slides went through almost as many versions as the risk table, labelling every player a threat or an opportunity before I rewrote it into three plain questions instead, what changes for that player, why it matters, and what we do about it, which was much more explainable and easy to follow.
Evidence forced a change elsewhere too. When I checked the €0.40 per order figure against where it actually came from, it turned out to be mostly payment fees rather than anything to do with running the software, so I split the two apart instead of leaving it as one number.
A surprise that occurred was that I assumed that the AI itself would be the part that caused the most problems. That was not the case, the model only interprets what the diner asks for and talks to them, while the application handles the nutrition maths and builds the order, so lots of the issues are to do with the restaurant, not with the app, such as wrong recipe data, or a kitchen that skips ingredients.
Another surprise was how much of governance had nothing to do with the AI, but more so with the app design. I hadn’t considered calorie floors to matter as much as they did, as the app could be encouraging someone to eat too little by rewarding restriction. I was also surprised in terms of privacy. I knew orders involved personal data in some loose sense, but I hadn’t really registered that a meal choice can reveal a health condition, which puts it under GDPR Article 9 rather than ordinary data. Once that was understood, consent and keeping only what’s needed in terms of data became an important part of the app’s design and was put into the slide.
Working through the agentic future question changed how I think about this product more than anything else in the project. I started by asking what our AI could do, and our assignment pushed towards what stays scarce once AI is enabled in everyone’s lives Reading a menu and estimating macros becomes free for everyone. What stays rare is a contract with a kitchen and a confirmed order, instead of always upgrading new technologies. If I did it again, I would check claims earlier rather than later, which would save a lot more time, and give more time for thinking and developing new ideas
