Grocer Guesser: building a game about grocery ingredients
Grocer Guesser is part of a series where I build small projects quickly and share exactly how they come together. The game is simple. You look at an ingredient list and try to guess which grocery item it belongs to. Some answers feel obvious. Others feel like someone shuffled random chemistry terms together and called it food.
The idea comes from trying to eat better and realizing how little I actually understand about the products I buy. I flip packages over and find surprises every time. Sometimes I see three clean ingredients. Other times I discover long paragraphs of preservatives, stabilizers, coloring, gums and scientific terms that look like they belong in a lab report.
At some point I realize these ingredient lists are unintentionally funny, oddly revealing and surprisingly educational. They feel like perfect material for a guessing game. So I decided to build one.
This blog post walks through my entire process from the moment the idea appears to the moment the game goes live. I explain the tools I use, how I set them up, how I work with Claude Code and how I test everything on a simple MacBook with basic WiFi. I also share the small tricks I use to keep projects moving even though I do not consider myself a developer.
The goal is to make this transparent and easy to follow so anyone can build something similar.
Why ingredient lists make great game material
The more I look at ingredient lists, the more they start to feel naturally playful. They reveal odd habits in the food world.
Some everyday foods have surprisingly elegant ingredient lists. Others contain ingredients nobody expects. Identical ingredients show up across completely unrelated categories. Some lists feel chaotic enough that you cannot guess the product at all.
Ingredient lists sit in a strange space. They are public information that most people never learn to interpret. You can buy a food item for years without ever truly understanding what you are consuming. That gap creates the perfect level of difficulty. It is trivia where everyone thinks they should know the answer but rarely does.
There is also an educational layer beneath the surface. Ingredient lists quietly reveal how foods are processed, how long they are meant to last and what tradeoffs manufacturers make. A lighthearted game becomes an easy way to get people curious about what they eat without lecturing anyone about nutrition.
This combination of amusement, surprise and hidden learning makes this idea stick for me.
Checking whether someone already built this game
Before I start building anything, I check whether the idea already exists. This research phase is not glamorous. It mostly looks like me typing into Google and hoping absolutely nothing comes up.
I search phrases like "ingredient guessing game", "guess the food from ingredients", and "food ingredient quiz". I find nutrition blogs, food science posts and some general trivia sites, but nothing that uses ingredient lists as the main mechanic. I even end up on Reddit threads where people suggest the idea and then move on, leaving it in the comment section. Like many internet ideas, it sits there unbuilt.
This gives me enough confidence to continue. If a concept is interesting, seems useful and does not exist yet, that is usually a good sign.
Keeping the build simple
My rule for these small projects is to pick tools that remove friction, free, and help me move fast. I am not trying to assemble a perfect technical stack. I am trying to see something working as soon as possible for as cheap as possible.
For Grocer Guesser the setup uses three key tools.
Vercel
Vercel handles hosting and deployment. I sign in with GitHub, connect a repository and Vercel deploys the site automatically. Every time I push changes, it rebuilds the project and updates the live version. I do not need to touch servers, configuration or anything complicated.
GitHub
GitHub is where the code lives. I use GitHub Desktop because it keeps everything visual. I can see files, write a short description of changes and commit without typing commands. When I push updates, Vercel sees the new version and redeploys the site.
Claude Code
Claude Code becomes the main engine behind the work. Instead of writing everything from scratch, I describe what I want and Claude generates the components, structure and logic. I still guide the process and shape the outcome, but Claude handles the technical heavy lifting.
This setup works well with my preference for free tools. I only pay for Claude at the $20 tier because it gives me enough power without being expensive. My site traffic is not large enough to justify higher paid limits, and free options usually get me ninety percent of the way.
I build everything on a simple MacBook with nothing more than WiFi. No fancy setup. No expensive equipment. Just the basics.
How I communicate with AI while building
The real work in this project happens in how I talk to Claude Code. Large models are powerful but very literal. They follow instructions precisely, even when those instructions are slightly ambiguous. Because of that, I have developed a workflow that keeps things structured and predictable.
I start with context
Every project begins with a summary of what the thing should do. This gives Claude a clear mental map of the goals before I ask for anything specific.
For Grocer Guesser my initial brief looks like: "Build a small game where the user sees an ingredient list and types the correct grocery item. They should receive feedback about which letters are correct and incorrect."
This short prompt removes confusion and guides the entire output.
I break the project into clear pieces
After giving context, I outline the required parts. Large models work better when the project is divided into logical sections.
For this game I ask Claude to create components such as a homepage with a Start button, a main game screen, a data file with real ingredient lists, and a results screen.
Having names for each part makes the structure easier to follow.
I ask for explanations
After Claude generates files, I ask it to explain everything it just created. These explanations teach me how different components connect while also helping me catch mistakes early.
I read them so that when something behaves strangely, I already understand the surrounding pieces.
I iterate in small steps
This habit saves hours of frustration. I never ask Claude to rebuild the entire project in one request. That usually breaks everything.
Instead I request very small adjustments. A new function. A change to the layout. A tweak to the logic. Then I test immediately.
Small steps keep the project stable and prevent giant cascading issues.
How I test on my laptop
My development machine is a basic MacBook running on ordinary WiFi. I download the project or clone the repository using GitHub Desktop and then open the folder locally.
To start the project I usually type npm install and npm run dev. The first command installs packages. The second starts the development server and prints something like Local: http://localhost:3000.
I paste that into my browser and the site loads as if it already exists online. When I change code and save the file, the browser updates almost instantly.
This tight feedback loop turns development into a smooth cycle. Change something. Refresh. See the update. Repeat.
What I do when something breaks
Something breaks every day. This is not a problem. It is simply part of building.
When I see a blank screen or a button stops working, I open the browser's developer tools. I right click, select Inspect Element and open the Console tab.
The console shows error messages that tell me what file or function is causing trouble. Sometimes the messages look cryptic but they always point somewhere useful.
If I see something like "TypeError Cannot read property map of undefined" or "Failed to fetch products.json", I copy the entire message, paste it into Claude and ask: "Act as a QA engineer. Debug this error and explain the fix."
Claude analyzes the issue, explains why it happens and generates the corrected code. This saves large amounts of time and makes debugging accessible even without deep technical training.
How I save progress with GitHub
Whenever the project reaches a stable state, I commit the changes in GitHub Desktop. A commit is essentially a snapshot in time. It captures the project exactly as it is so I can always restore that version if I break something later.
My workflow becomes predictable. I run the project. I find a bug. I open the console. I paste the error into Claude. I apply the fix. I test again. I commit the update.
Repeating this cycle creates consistent progress with minimal stress.
Planning the first version
I always release the smallest version first. For Grocer Guesser I define the minimum viable version as something that includes real products, ingredient lists, multiple choice answers, feedback for correct and incorrect responses, and a scoring loop.
There are no accounts. No leaderboard. No advanced animations. No design system. Only the essential game loop so I can test whether the idea is fun and worth expanding.
Keeping the first version simple prevents me from getting stuck in debug mode when things break.
That is good enough for version one. That's all for tonight. Stay tuned for part 2!