I Built an AI Food Scout Because “What Should I Eat?” Is a Surprisingly Hard Question 🍜

Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady Submission 🦥

This is a submission for the "Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady" ( https://dev.to/challenges/hacktoberfest-week3-2026-10-19 )

You're hungry. You have a budget. Maybe you're trying to hit a protein target, stay under a calorie limit, or just eat something other than the same three meals you've been ordering for weeks.

You open a food delivery app and start scrolling.Twenty minutes later, you've seen 47 dishes, opened six restaurant pages, and still have absolutely no idea what to order.

The problem isn't a lack of food choices. It's having to do all the work of finding the right ones.

That's why I built CraveCode, an AI-assisted food discovery system that searches for meals around your preferences, filters unsuitable options, and ranks the remaining choices.

The goal? Less scrolling, less guesswork, and more time enjoying the food.

CraveCode helps answer a deceptively difficult question:

What can I eat that fits my goals, preferences, and budget?

Instead of starting with a restaurant catalogue, you start with a meal brief.

You can specify your dietary preference, protein target, calorie ceiling, budget, preferred cuisine, meal timing, and the kind of food you're craving.

CraveCode then discovers candidates, filters them against your requirements, ranks them, and diversifies the results.

The system can return up to 15 ranked options, with the actual number depending on the candidates available.

The interesting part isn't simply that an AI recommends food. It's that the application combines search, explicit constraints, deterministic ranking, and optional AI exploration rather than asking a language model to invent the entire answer.

Try it: "CraveCode live preview" ( https://cravecode.onrender.com )

A note about the render preview: The public Render preview uses SerpApi for public web discovery. The richer signed-in Swiggy menu-search experience is supported through the local setup(As it requires swiggy production access which is under process). These are different discovery modes, and a public search result does not guarantee current availability or a verified menu price.

GitHub repository: "SarveshDujari/CraveCode" ( https://github.com/SarveshDujari/CraveCode )

CraveCode is built with React, Vite, Node.js, TypeScript, and Mastra, with integrations for Gemma, MongoDB Atlas, SerpApi, and Render.

Explore the repository to see how the search workflow, candidate filtering, ranking logic, and optional AI-powered dish expansion fit together.

I didn't want CraveCode to be a chatbot that returns a convincing paragraph about food and leaves the user to verify everything.

I wanted a system that actually searches for candidates, applies rules, and explains what it knows.

Meal brief | v React + Vite UI | v Node.js / TypeScript API | v Mastra workflow Plan -> Discover -> Verify | +-------+-------+ | | v v Swiggy MCP SerpApi Local menu search Public discovery | | +-------+-------+ | v Normalize candidates | v Filter -> Score -> Diversify | v Ranked recommendations Extra integration:local Gemma, MongoDB Atlas Enter fullscreen mode Exit fullscreen mode Mastra: orchestrating the discovery workflow Mastra provides the workflow structure for planning discovery, retrieving candidates, and processing the results.

The key design decision is that orchestration doesn't own every business rule. The workflow connects the discovery stages, while the application code handles important eligibility checks and ranking decisions.

That makes the system easier to inspect, debug, and improve than a single prompt responsible for the entire process.

The signed-in local setup can use Swiggy MCP to search menus associated with a saved delivery address.

This enables a richer discovery experience using returned menu information, including prices and availability-related signals where provided.

I keep this distinct from the hosted preview. The existence of a restaurant page is not equivalent to a confirmed, currently orderable menu item.

The Render preview uses SerpApi to find relevant, city-specific Swiggy pages.

The application checks query relevance, retains suitable delivery-page URLs, and removes duplicates and generic results.

These results are treated as leads for discovery, not as verified menu data. That distinction matters because a search engine cannot guarantee a dish's current price, stock, nutrition, or delivery eligibility.

CraveCode uses a locally served Gemma model for the Explore more dishes feature.

Instead of asking the model to rank every item or decide whether a meal satisfies every hard constraint, I use it for a focused task: proposing additional dish-search terms.

The application validates those suggestions against an allowlist and structured-output requirements. If the output is malformed or unsuitable, deterministic fallback choices are available.

This keeps the AI feature useful without making the entire application dependent on a model endpoint.

MongoDB Atlas supports persistence for completed searches, candidates, and shared usage-budget counters.

Those counters are especially important when the public preview relies on an external search service. If the hosted budget store is unavailable, paid SerpApi requests are stopped rather than proceeding without the intended shared budget protection.

Render hosts the public preview, so people can try the interface without setting up the full local environment.

The deployment has its own limitations, particularly around signed-in menu access. Documenting those limitations makes the demo more honest and helps developers understand what they need to reproduce the richer local experience.

The model proposes. The application checks. The evidence determines what can be claimed.

For example, a model-generated dish idea still needs to pass through the discovery pipeline. A public search result doesn't become a verified menu item just because it looks relevant. And a broad nutrition estimate doesn't become a restaurant-specific nutritional fact.

That separation is the core of how I approached the project.

An LLM can suggest the perfect meal, but it can't guarantee that the dish is available, affordable, or nutritionally accurate.

So I split the responsibilities: Gemma explores new dishes, search discovers candidates, and deterministic code handles filtering and ranking. Uncertain prices and nutrition estimates remain just that: estimates.

This made CraveCode easier to debug and gave me more control over its recommendations.

Nutrition is the biggest opportunity. CraveCode currently uses broad, hand-authored nutrition ranges for supported dish types. They are estimates, not verified values for a particular restaurant's recipe or serving.

I'd like to improve that with more reliable item-level nutrition data, stronger evaluation of live discovery, and clearer verification of final payable prices and availability.

Also would like to add the swiggy integration to render after getting approval.

The intended payoff is straightforward: less manual searching, less repetitive scrolling, and fewer unsuitable choices to inspect.

Instead of separately browsing restaurant pages, checking every dish against a budget, and comparing a long list of similar items, a user can start with their constraints and receive a filtered, ranked shortlist.

The right way to measure this would be to compare the time needed to find a suitable meal manually against the time needed with CraveCode, across several realistic meal briefs.

I'm entering the categories that match CraveCode's actual integrations and that I can demonstrate in the submission:

I'll verify the current official partner-category rules before final submission and remove any category for which I cannot provide the required evidence.

Live preview: https://cravecode.onrender.com

GitHub: https://github.com/SarveshDujari/CraveCode

Demo video: [ https://youtu.be/DoDybTKEgkY?si=wDeZN4zPQzU3ZKSR ]