Plant Doctor 🌱: Turning AI Plant Diagnosis Into Real-World Plant Care

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

I built Plant Doctor, an AI-powered plant-care assistant that helps people understand what might be happening to their plants using a photo.

The idea behind this project is simple: instead of using AI only to generate text or answer questions, what if we used it to help people take action in the real world?

With Plant Doctor, users can upload a picture of a plant and receive an assessment containing:

🌿 Plant identification when possible

🔍 Visible symptoms and possible issues

🪴 Practical care recommendations

📊 A model-generated confidence estimate

📅 A suggested time to check the plant again

Users can create an account and revisit previous assessments through their personal plant journal.

Plant Doctor is designed for beginners, houseplant owners, and anyone who wants a starting point for caring for their plants without needing to understand plant diseases beforehand.

The goal isn't to replace experienced gardeners or botanists. An image cannot always reveal the exact cause of a plant's symptoms, so the application should communicate uncertainty rather than present every AI suggestion as a confirmed diagnosis.

Most importantly, the assessment should lead to something outside the screen: inspecting leaves, checking soil moisture, improving plant care, and observing how the plant responds.

Demo

🌱 Live application: https://plant-doctor-1-g8ic.onrender.com

You can create an account, upload a plant photo, view the assessment, and revisit saved diagnoses.

The application is deployed on Render, with a FastAPI backend and MongoDB Atlas database.

Code

💻** GitHub repository:** https://github.com/meetrathod0729-hub/Plant-Doctor

The repository contains the frontend, backend, AI provider integrations, and supporting evaluation code.

Feel free to explore the implementation and share suggestions or improvements!

How I Built It

I wanted to build a complete application rather than stop at a standalone AI model demo.

Tech stack:

Frontend: React, Vite, Tailwind CSS

Backend: Python and FastAPI

AI: Gemini Vision API for the deployed application

Local AI exploration: Ollama with Qwen2.5-VL

Database: MongoDB Atlas

Deployment: Render

The diagnosis pipeline works like this:

The user uploads a plant image.

The backend validates the uploaded file, corrects its orientation, and resizes it.

The image is sent to the configured vision model.

The model returns a structured assessment containing observations, possible issues, recommendations, and a suggested follow-up interval.

The backend validates the response and saves the diagnosis for the authenticated user.

The frontend displays the assessment and adds it to the plant journal.

One important design consideration was handling uncertainty. Brown spots, yellowing leaves, and other visible symptoms can have multiple causes. Plant Doctor therefore needs to distinguish observable symptoms from possible explanations and avoid presenting a model-generated confidence estimate as a calibrated probability.

For deployment, I used Gemini Vision so the application could run without requiring visitors to have a local model installed. I also explored running Qwen2.5-VL locally through Ollama, which gave me a way to experiment with local vision inference.

Why Does Open Innovation Matter?

Open innovation matters because it gives developers opportunities to experiment, learn, and build on existing work without having to create every component from scratch.

While developing Plant Doctor, I explored local inference with Ollama and Qwen2.5-VL. Running a vision model locally helped me understand the practical challenges of working with image inputs, hardware constraints, model responses, and structured outputs.

My deployed application currently uses Gemini Vision, so I wouldn't describe the production inference pipeline as entirely open-weight. However, experimenting with open-weight models gave me another approach to investigate and compare.

That flexibility matters. Developers can explore local models, compare approaches, learn about resource requirements, and decide which solution best fits their use case.

Open innovation also makes it easier for people to inspect implementations, share improvements, and learn from one another. Projects like Plant Doctor can become starting points for further experimentation rather than isolated demos.

My Agent Session

I haven't included a DevRelay agent session in this submission. If I capture one, I'll add it here.

Prize Categories

Primary challenge: Hacktoberfest Open-Source AI Challenge Week 1 — Touch Grass.

I'm submitting Plant Doctor as a project that uses AI to encourage a practical, real-world activity: taking care of plants.

Final Thoughts 🌱

Building Plant Doctor taught me that an AI application doesn't have to keep someone chatting with a model to be useful.

Sometimes, a good AI interaction should end with someone putting their phone down, walking over to a plant, inspecting its leaves, and taking a small step to help it grow.

That's the experience I wanted to build with Plant Doctor.

Try the demo: https://plant-doctor-1-g8ic.onrender.com

Explore the code: https://github.com/meetrathod0729-hub/Plant-Doctor

I'd love to hear what you'd improve or what features would make this more useful for plant owners!