This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.
What I Built
I built PlantWise AI, a location-aware plant discovery and growing suitability application that helps people understand plants and explore whether they may be suitable for growing in their area.
The idea started with a simple question: What if someone could enter the name of a plant, select their location, and understand its growing requirements before deciding to grow it?
PlantWise AI brings plant information, location-based growing suitability, and AI-assisted gardening guidance into one application.
Users can explore a plant, provide their location, review its growing requirements, and get guidance through an AI assistant. Instead of keeping people limited to reading about plants online, the goal is to help them take that knowledge outside, start exploring plants, and make more informed decisions about gardening.
The project is designed for beginners, gardening enthusiasts, and people interested in growing plants at home.
One important design decision is that the suitability engine does not depend on a language model. The core application can continue working even when the hosted AI assistant is unavailable.
Demo
Live application: https://plantwise-1.onrender.com/
The frontend and FastAPI backend are deployed on Render.
The demo showcases the plant discovery experience, location-based growing suitability, and AI-assisted plant guidance.
Code
GitHub repository: https://github.com/aniket937/PlantWise
PlantWise AI
A growing-suitability assistant for crops and vegetables. Pick a plant, enter a location, and the app compares the site's historical climate against that plant's documented agronomic requirements β and explains the reasoning.
The suitability verdict is not a ratio or a score. It is a weighted rule-based assessment: each requirement (cold tolerance, heat tolerance, frost risk, growing-window length, water balance, soil, sunlight) is evaluated against a documented range and reported as pass / caution / fail / not assessed, and the verdict is reached from those. Unknown values are reported as unknown rather than guessed.
The project is deliberately honest about its limits: climate values are climatological normals for a reanalysis grid cell, not a forecast, and a positive verdict is a good signal, not a guarantee.
Repository layout
-
backend/β FastAPI application, SQLAlchemy persistence, climate + AI services, suitability engine, pytest suite. -
frontend/β Next.js 16 applicationβ¦
How I Built It
I built PlantWise AI using Next.js, React, TypeScript, Tailwind CSS, Python, and FastAPI.
The frontend provides the user interface, while the FastAPI backend handles application APIs, configuration, and AI integration. The project is deployed on Render, with the frontend and backend running as separate services.
For the AI assistant, I integrated the open-weight Gemma model google/gemma-4-26b-a4b-it:free through OpenRouter.
Initially, I planned to run an AI model locally using Ollama. However, my machine did not have Ollama installed, and downloading a multi-gigabyte model was not practical given my available disk space and the hackathon deadline.
Instead of abandoning the AI feature, I adapted the architecture to use hosted inference with an open-weight model. This allowed me to integrate the assistant without storing the model weights on my laptop.
The main technologies used were:
- Frontend: Next.js, React, TypeScript, and Tailwind CSS.
- Backend: Python and FastAPI.
- AI: Gemma open-weight model accessed through OpenRouter.
- Hosting: Render.
- Version control: GitHub.
A key architectural decision was keeping the suitability engine independent of the LLM. The AI assistant provides additional explanations and guidance, but the core application does not need a language model for every operation.
This separation also makes failures easier to handle: when the hosted assistant is unavailable, the rest of the application can remain usable.
Why Does Open Innovation Matter?
For PlantWise AI, open innovation was not just a technology choice. It helped me build around the constraints I actually had.
1. Open-weight AI made the project practical
Running a large model locally was not feasible on my laptop because of storage constraints. Using an open-weight Gemma model through OpenRouter allowed me to integrate AI without downloading several gigabytes of model weights.
This made it possible to focus my limited development time on building the actual product rather than setting up local inference infrastructure.
2. The model is replaceable
I wanted the application to depend on a clearly defined AI service rather than being permanently tied to one model.
Using a configurable model ID means I can evaluate other compatible open-weight models in the future. Different models can be tested for response quality, latency, cost, and suitability for plant-care questions without redesigning the entire application.
This flexibility is valuable because an AI model that works well today may not be the best choice as better models become available.
3. Open innovation helped me build within limited resources
A hackathon project should demonstrate useful engineering, not require expensive infrastructure before it can be tested.
The hosted free-model option allowed me to start experimenting without purchasing dedicated inference hardware or downloading a local model. Free access has provider limits and may change, so this does not mean the application is guaranteed to cost nothing to operate indefinitely.
4. I separated AI from the core application
I did not want a language model failure to make the entire product unusable.
Plant information and growing suitability remain separate from the hosted AI assistant. This creates a more resilient architecture and reduces unnecessary dependence on model availability.
5. Transparency matters as much as intelligence
A language model can produce convincing explanations even when the underlying information is incomplete. For a gardening application, that can lead to poor decisions.
My approach is to keep the suitability assessment separate from AI-generated explanations. Environmental suitability should be based on available supporting information, and missing data should not be disguised as certainty.
What Open Innovation Does Not Solve
The AI assistant still requires an internet connection because inference is hosted through OpenRouter. User context sent to the provider is also subject to the provider's data-handling policies.
The current architecture does not claim fully offline AI or complete local data privacy. Instead, it demonstrates a practical way to use an open-weight model while retaining the flexibility to change models and keeping the core application independent of the AI service.
For me, this is the value of open innovation: it provides alternatives, flexibility, and opportunities to build useful software without assuming access to expensive hardware or proprietary model infrastructure.
How PlantWise AI Fits the "Touch Grass" Theme
The theme is about making the screen the shortest part of the experience.
PlantWise AI approaches this through plant discovery and growing guidance. A user can learn about a plant, understand its requirements, and use that information to decide what to explore or grow in the real world.
The long-term goal is to make the transition from online information to offline action easier: choosing a plant, observing local growing conditions, preparing a garden, or starting a small growing project.
The application is not intended to replace real-world observation or local agricultural expertise. It is intended to help people get started with better information.
Prize Categories
- Best Use of Render
- Best Use of Gemma
Top comments (0)