DEV Community

Meet Rathod
Meet Rathod

Posted on

I Built My Friend an AI-Powered Allergy-Safe Meal Planner 🍳🤖

Hacktoberfest: Contribution Chronicles

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built
I wanted to build something useful for a friend rather than another generic AI chatbot or an AI project built just for the sake of using AI.
The idea came from a simple problem:
Meal planning can become frustrating when you have food allergies.
You have to check ingredients, think about what you already have at home, make sure nothing unsafe is included, and then figure out whether you can actually prepare the meal.
So I thought:
What if you could tell an application what you're allergic to and what ingredients you have, and it could suggest meals around those restrictions?

That became Allergy-Safe Meal Spinner.
The application lets a user enter:

  • Allergies or ingredients they need to avoid
  • Ingredients currently available in their kitchen Then they click Spin, and the application generates 3 meal ideas based on those constraints. Each meal includes:
  • Meal name
  • Ingredients
  • Cooking instructions
  • Safety information During testing, the application generated meals such as:
  • Classic Tomato Egg Stir-Fry
  • Fresh Tomato Pasta
  • Stovetop Pasta and Tomato Frittata The generated meals are also stored in MongoDB Atlas, so previous meal ideas aren't lost. The main idea was to make the interaction extremely simple: Tell it what you can't eat + tell it what you have → get meal ideas. Important: This is an AI-powered meal-planning application and is not a substitute for professional medical or allergy advice. Anyone with serious allergies should independently verify ingredients before consuming a generated meal.

🌐 Live Demo:
https://allergy-meal-spinner.onrender.com/
The deployed application lets you enter allergies, add what's available in your kitchen, and generate three meal suggestions.
Code

💻 GitHub Repository:
https://github.com/meetrathod0729-hub/allergy-meal-spinner**
The complete project is open source.
How I Built It
The application is a full-stack AI application built with React, FastAPI, Gemini and MongoDB Atlas.
The basic architecture is:
React + Vite + Tailwind CSS
↓
FastAPI Backend
↓
Gemini API
↓
Generated Meals
↓
MongoDB Atlas

Frontend
The frontend is built using:

  • React
  • Vite
  • Tailwind CSS It handles the allergy selection, pantry ingredients, meal generation interface and meal history.

Backend
The backend is built using:

  • Python
  • FastAPI
  • HTTPX The /api/spin endpoint receives the user's allergies and pantry ingredients. The backend then constructs a request containing information such as: Allergy list — ingredients that must be avoided Pantry — ingredients currently available The request also asks the model to generate exactly three meals and return the result as JSON.

AI Generation
The deployed version currently uses Gemini 3.8 Flash for meal generation.
I use a system prompt containing the application's meal-generation rules and pass the user's allergies and available ingredients as additional context.
The model is instructed to return structured JSON containing the generated meals.
The backend then parses that response before sending it to the frontend.

MongoDB Atlas
MongoDB Atlas is used to persist meal history.
For each successful generation, the application can store:

  • Allergies
  • Pantry ingredients
  • Generated meals
  • Model used
  • Timestamp This turns the project from a simple: Input → AI → Output application into something where previous results can actually be revisited.

Handling AI failures
This ended up being one of the most interesting parts of building the project.
During development, I encountered situations where the exact same request that had worked earlier suddenly returned:
503 Server Unavailable
My first thought was:
"Something is wrong with my code."

So I started checking the backend, request payload, API configuration and model setup.
But my terminal also showed successful requests such as:
Generated 3 meals
POST /api/spin 200 OK
The same application could work successfully and then temporarily receive a 503 from the external AI service.
That made me realize that an AI application cannot simply assume that its model API will always be available.
So I added retry handling for temporary failures.
The backend specifically handles:

  • 429 — rate limiting
  • 500 — server errors
  • 503 — service unavailable
  • Request timeouts For temporary failures, the application retries the request with increasing wait times instead of immediately failing. This was one of the biggest engineering lessons from the project: The AI model is only one part of an AI application.

The application around it also needs to handle failures, unexpected responses and external dependencies.
Local AI experimentation
During development, I also experimented with Ollama and local AI models.
The deployed version ultimately uses Gemini, but experimenting with local inference helped me understand the trade-off between relying on a hosted model and having the ability to run models locally.
It also influenced how I think about the AI layer of an application.
I don't want the rest of the application to be so tightly coupled to one model that changing the model requires rebuilding everything.
Why Does Open Innovation Matter?
This project made me realize why having alternatives to a single hosted AI provider is valuable.
The deployed version uses Gemini, but during development I experimented with local inference through Ollama.
That gave me the opportunity to explore a different approach to AI:
Cloud model → convenient and easy to deploy
Local model → more control and less dependency on an external API
The experience became particularly relevant when I encountered intermittent 503 responses from the hosted model.
Having experimented with local AI gave me another way to think about the problem instead of treating the external API as the only possible solution.
For me, open innovation means being able to experiment with different models and approaches and build the surrounding application in a way that isn't completely locked to one provider.
I also learned that the AI layer should ideally be replaceable.
The frontend shouldn't need to know which model generated a meal. The backend should be able to handle the model interaction and return a consistent structured result.
That makes it easier to experiment with different models in the future.

My Agent Session
I used an AI coding agent during development to help with implementation, debugging and iteration.
The development process involved going from the initial idea to:

  • Building the React interface
  • Creating the FastAPI backend
  • Integrating Gemini
  • Connecting MongoDB Atlas
  • Designing the meal-generation prompt
  • Handling structured AI responses
  • Debugging intermittent 503 errors
  • Experimenting with local AI through Ollama
  • Testing generated meals
  • Deploying the application

Agent session:
I will add my DevRelay session here if required.

Prize Categories

🗄️ Best Use of MongoDB Atlas
I am entering the MongoDB Atlas category.
MongoDB Atlas is an actual part of the application's architecture and is used to persist generated meal history.
Instead of treating each AI generation as temporary, the application stores the user's inputs and generated results so they can be retrieved later.
This was important to me because I wanted to build a complete application around AI rather than just a page that sends a prompt and displays a response.

Final Thoughts
This project started with a simple question:
"Can I build something that my friend would actually find useful?"

It ended up teaching me much more than how to connect an AI API.
I learned about:

  • Full-stack development
  • AI integration
  • Prompt design
  • Structured AI responses
  • MongoDB persistence
  • API failures
  • Retry strategies
  • Local AI experimentation
  • Deployment But the biggest lesson was this: The model is only one part of an AI application.

The real engineering happens around it.
You have to think about what happens when the API fails, how the data is stored, how responses are validated, how the user interacts with the system, and how easily the AI component can be changed.
I didn't just learn how to make an AI generate recipes.
I learned how to build an application around AI. ❤️

hacktoberfest #devchallenge #ai #opensource #mongodb #react #fastapi #webdev

Top comments (0)