Eat-What

“What should I eat today?” is often difficult not because there are no options, but because there are too many and each one has a reason to remain in consideration. Eat-What is a lightweight decision tool built from my own choice paralysis. Users switch between food and drink, narrow the pool by occasion, flavor, and temporary exclusions, and then let the tool return one clear result. It does not search restaurants or call a large model at runtime. The project is an AI Coding exercise in turning a recurring personal need into a working product.

The project began with observation of my own daily decisions rather than formal user research. Three problems kept recurring when choosing delivery, group meals, or an afternoon drink: more candidates created longer comparison loops; uniform randomness could return an option that clearly did not fit the current context; and each decision restarted from zero because previous satisfaction was never reused. The product opportunity was not to provide more recommendation content, but to reduce the decision to a few necessary boundaries and help the user accept a sufficiently suitable result.

The first version aimed to create the shortest possible decision path without discarding personal preferences. Users should be able to switch between food and drink, narrow candidates by occasion, flavor, and temporary exclusions, and receive a result with one action. Ratings should influence later draw weights, while frequently used candidates, categories, and history remain stored locally. Future validation should measure time from opening the page to accepting a result, redraw frequency, result acceptance, and continued usage. No quantitative evidence exists yet, so the project does not claim that choice paralysis has already been reduced.

The project did not include interviews, surveys, or large-scale behavioral research. I decomposed the need by observing my own decision process: the choice object separates into food and drink; context changes across solo meals, gatherings, late-night food, and afternoon tea; flavor cues such as sweet, spicy, or light quickly remove unsuitable options; some candidates are unwanted only for the current round and should not be deleted permanently; and earlier satisfaction should affect future likelihood. These variables shaped an MVP focused on a personal usage loop rather than a complex recommendation system.

The main interface centers on a single picker. Users switch between food and drink at the top, use a filter panel for occasion and flavor, and apply temporary exclusions to define the current boundary. After the draw starts, candidate names cycle quickly before stopping on the result. The user can rate it from one to five stars or exclude it from the current round. A settings panel supports adding, editing, deleting, categorizing, and tagging candidates, while the history panel keeps the latest 20 results and their ratings at selection time. The final draw is not uniformly random: candidates are filtered first, then each remaining item’s rating becomes its weight. This balances the decisiveness of randomness with respect for established preferences.

The demo is a single-page application built with React 19, TypeScript, and Vite. Tailwind CSS provides the interface styling, while Motion handles mode changes, candidate cycling, and side-panel feedback. Food, drinks, categories, and history are stored separately in browser localStorage, so the tool requires neither an account nor a backend. AI Coding helped translate decision variables into state and interaction flows, generate and refine the component implementation, inspect behavior, and iterate. The repository retains a Gemini SDK dependency, but the current source contains no model call; the product behavior comes from frontend rules and local data rather than generative AI.

The current output is a publicly accessible frontend demo and GitHub repository. It covers food and drink modes, default and custom pools, categories and labels, occasion and flavor filters, temporary exclusions, rating-weighted randomness, the latest 20 history entries, and local persistence. It demonstrates an end-to-end AI Coding path from a personal problem definition to an interaction loop and running implementation. Evidence on user volume, decision efficiency, result acceptance, or retention is not yet available; those remain future validation work.

The project reinforced that a decision tool does not always need a more sophisticated explanation. The key is to let users express boundaries with minimal effort and feel comfortable delegating the final step. The next engineering pass should correct filter callback dependencies, interval cleanup, and malformed local-data handling, then split the concentrated component into maintainable units. Product validation should test whether rating-weighted randomness actually improves acceptance and whether repeated results need a cooldown. Shared candidate pools, collective exclusions, or voting could support group decisions later, but only after the individual loop is stable.