What I actually did was build Globite as a mobile app for pantry and fridge inventory, expiration tracking, barcode scanning, ingredient-based recipe search, substitutions, cooking instructions, timers, and a world map for exploring cuisines. I came into this independent project thinking I was building an inventory-aware cooking app, and I left feeling like the lesson was much more so about scope, especially with vibe-coded prototypes. The useful center of the project was probably (read: definitely) smaller than the app I made. It was less “help me cook a full recipe from start to finish” and more “help me remember what food I have before I forget about it, rebuy it, or let it expire.” That sounds obvious now, but it didn’t feel obvious while I was building, partly because every new feature seemed close enough to the problem I was studying to justify adding. Unfortunately, you guys were right in that new is not always better. The usage of AI tools was both a pillar of success and also a major drawback on failure.
I also do not want to make this sound like I barely did the project and then discovered it was too big. A lot happened. I made two moodboards, a stylesheet, a semi-full Figma prototype, and the app itself. I also ran 11 total interviews, including 5 people who participated in a diary-study-like Google Form after using the app, so I had both interview feedback and more in-the-moment reflections. In a lot of ways, I completed most of the deliverables I would associate with CS247B: visual exploration, design system work, prototyping, research, testing, and reflection. But doing that much work didn’t prevent scope problems. If anything, in all honesty the amount of work made the prototype feel even more legit, which made it easier to miss that the core design still needed more focus.
Before the project, I thought the problem was mostly about recipe discovery. People have food in their fridge, they forget about it, food expires, and then they feel bad about wasting it. Super simple, right? So the solution seemed pretty straightforward: let users enter their ingredients, then recommend recipes that use those ingredients. From there, the idea expanded in a way that felt natural at the time based on the conversations I was having with people around me. If someone was missing an ingredient, Globite could show substitutions. If someone was cooking, it could show step-by-step instructions. If cooking felt repetitive, it could make exploration more playful through a world map. To be fair, I thought this was genuinely exciting, which is why I proposed it as my quarter-long project. My personal pitch was that it felt like food waste, cooking, sustainability, and discovery could all live inside one product.
In retrospect, I think that connection was more fragile (like, a lot more fragile. Some real tenuous s**t) than I realized. The features were all in the same food/cooking universe, but they were not asking for the same thing from the same users. For instance, checking ingredients is quick and almost casual. Recipe search inherently takes more attention. Cooking mode assumes the user has already decided to make something. A cuisine map (my least successful feature) depends on curiosity, motivation, and maybe a little competitiveness. Scanning asks users to do setup work and trust the app’s interpretation. I treated these as one system because they belonged to the same domain, but I didn’t fully treat them as different interaction states. That was one of the major design lessons I learned this quarter.
The research also kept pointing toward something simpler! I used informal surveys and interviews through friends and people in our networks, mostly young adults who managed their own groceries and food routines. What kept showing up was that people’s food systems were not especially organized. (Mine too…) A lot of people just check the fridge. They remember some things and forget others. They buy groceries based on a vague sense of what they think they are out of. They lose track of items that are not visible. Food decisions also tend to happen when people are tired, hungry, busy, or already leaning toward takeout. In that context, the inventory feature showed the highest value because it could almost act like an external memory. I basically rediscovered the joys of cognitive offloading (thanks, @jameslanday).
I think that should have been the center of the project for longer. The ingredient-checking moment had a clear shape, approximate eye tracking and all. Someone opens the app, sees what they have, remembers the spinach, notices the eggs, avoids buying another yogurt, or decides to use something before it goes bad. That is not as flashy as a recipe platform or a gamified cuisine map, but it is much closer to how food waste often happens. It is not always caused by one big failure to plan.
The problem is that once I had that idea, I kept building around it. Vibe coding made this worse because adding features felt so available. A substitutions screen sounded useful, so I added one. A cooking flow sounded useful, so I added one. A map sounded fun and tied nicely to the food exploration angle, so I added that too. None of these ideas were random, but they blurred the gap I was actually attempting to fill. I can’t force users to want to gamify their relationship to food, especially when my intended user base is just trying to get by in a new city. I think my gamified dream app could have worked a lot better for a different user base.
The usability testing helped me see that tension(?) without making the whole project feel like a failure. Users understood the concept. They liked expiration tracking. Recipe search made sense to them. Substitutions seemed promising. The world map was fun (especially after initial iteration!!). So the flaws were critical, but obviously not breaking. They didn’t show that Globite was useless or that the concept had no value. I would argue that rather than that, these flaws showed that each feature needed much more design care than I had given it. Scanning needed better onboarding because it was easy to assume that LLMs are all-knowing. Substitutions needed explanations because ingredients are not interchangeable just because they fall into the same category. The map needed a stronger connection to the ingredients users already had.
People didn’t really use Globite like a full meal-planning system. Actually, literally the exact opposite. They opened it briefly, checked inventory, and didn’t always continue into recipes or exploration. At first, I could have seen that as users failing to reach the more important parts of the app. But I think that reading would miss the point. Maybe the value wasn’t always getting someone to cook a full meal. Sometimes the value was helping them remember they had food at all. Quote from a friend who stress-tested the app for two weeks: “Holy s**t this saved me so many times because every time I go to the f***ing store I always f***ing forget what I have in my fridge.”
That super shifted how I understood the prototype. I had been treating inventory as the setup layer, as if users would add ingredients so the recipe engine could do something more impressive afterward. But maybe the inventory was the main interface to focus on (even thought my UI was admittedly overly utilitarian at first). Maybe the first ten seconds mattered more than the full recipe flow. What do I have? What is going bad? What can I eat quickly? What should I not buy again? These are small questions, but they are also the questions people ask while standing in front of a fridge or walking into a grocery store.
The biggest lesson I am taking from this is that beyond being a management issue, scope changes a product’s meaning. You might be thinking this is really obvious, but this is unfortunately not something I am convinced I had internalized properly. Scope changes what the app seems to prioritize and what users think they are supposed to do. With Globite, more features made the app feel more complete, but they also made the core interaction harder to see. I think vibe-coded prototypes are especially tricky for this reason. They make scope creep feel productive! I never again will code “stretch goals” together with my main goals in one iteration.
If I did this again, I would still value the amount of work I did, because the moodboards, stylesheet, Figma, app, interviews, and diary-style responses all helped reveal what was working and what wasn’t. But I would build the next version with more restraint. I would make the inventory the home screen. I would focus on what users see immediately: ingredients available now, items expiring soon, and a few quick actions like “used up,” “still have,” “eat fast,” or “use soon.” I would test whether people open the app before eating or shopping, and I would care more about whether the app helps users remember food than whether they complete a recipe.
I would also make new features earn their place more slowly. Recipe search should come after the ingredient-checking loop feels solid. Substitutions should come after I see users getting stuck because they are missing ingredients. A world map should only exist if cuisine exploration helps people act on food they already have. I still like the map, and I still think there is something interesting there, but I do not think I earned it in the design yet.
Overall, Globite taught me that doing a lot of work is not the same as having a focused product. I did a large amount of design and research work, and that made the project fleshed out enough to expose its weaknesses. The weaknesses were good starting points and still definitely act as guiding points, but they didn’t collapse the idea. I will interpret their impact as that they pointed toward a cleaner version of the app. Hopefully I’ll get a chance to iterate again.
