DEV Community: Ravindar Amogh Gummadavelly

NaturaDex

Ravindar Amogh Gummadavelly — Sun, 11 Oct 2026 18:06:08 +0000

NaturaDex 🌿 — A Real-World Pokédex That Wants You to Put Your Phone Away

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

What I Built

What if discovering nature felt less like searching the internet and more like catching a Pokémon in the real world?

That idea became NaturaDex — the Eyes-Up Nature Companion.

Imagine walking through a park, hiking a trail, or exploring your own neighborhood. You notice an unfamiliar plant. Instead of opening multiple tabs, scrolling through articles, and spending the next ten minutes staring at your phone, you take a photo, get a short identification-style explanation, listen to the information, and put your phone away.

That is the experience I want NaturaDex to create.

🌱 The idea is simple:

Discover: Take a picture of a plant or another interesting natural observation.
Understand: Receive structured information, including a common name, scientific name, visible characteristics, and habitat information.
Listen: Hear a short narration instead of reading a long explanation on your screen.
Remember: Save the discovery to a personal nature journal.
Look up: Put the phone away and return your attention to the real world.

NaturaDex is designed for curious walkers, hikers, gardeners, students, and anyone who wants to learn more about the living world around them.

My favourite part of this concept is its definition of success: the best interaction is the one that helps you stop interacting with the app.

The screen should be the shortest part of the experience.

Demo

💻 Source code: NaturaDex on GitHub

The current Flask prototype includes:

A responsive, nature-inspired interface.
Image upload and validation.
A structured vision-identification interface.
A clearly labelled Demo Mode with sample plant records.
Listen, pause, resume, and stop controls using browser speech synthesis.
A SQLite-powered discovery journal with save, view, and delete functionality.
Basic safety messaging to discourage eating or handling plants based solely on an identification result.

An important distinction: Demo Mode uses predefined examples. Its sample results are not generated from the uploaded photograph. The real vision-provider integration is implemented, but live identification has encountered network issues and has not yet been reliably verified in my environment.

Code

Explore the project here:

🔗 github.com/Ravindar-Amogh-Gummadavelly/NaturaDex

The project is built with a deliberately straightforward architecture:

Python and Flask for the application and API routes.
HTML, CSS, and JavaScript for the user interface.
SQLite for the local discovery journal.
Pillow for image validation.
Browser Web Speech API for narration.
A vision-provider abstraction to separate identification logic from the rest of the application.

I also added tests for image validation, journal operations, provider behaviour, and Demo Mode. The latest local test run reported by my development environment was 49 passing tests.

How I Built It

I started with the experience I wanted people to have outdoors, rather than starting with a model and looking for a reason to use it.

That led to one core design principle: Eyes-Up AI.

Most AI interfaces encourage people to keep asking questions, reading responses, and remaining on the screen. NaturaDex should do the opposite. It should give people enough information to understand an observation and then encourage them to continue exploring.

I built the first working application in Python using Flask, with a small frontend and a SQLite journal. I added image validation, a structured identification response, safety messaging, audio controls, and persistent journal operations. I also introduced a provider abstraction so that the identification engine can evolve without requiring a complete rewrite of the application.

For the current prototype, I implemented a Gemini vision-provider integration. I also began preparing a BioCLIP-2 provider for the longer-term goal of local biological image identification.

However, the distinction between implementation and completion matters: BioCLIP-2's local model weights have not yet been downloaded and validated in the application. Fully offline AI identification is a future milestone, not a capability I am claiming for the current version.

To make the interface demonstrable while troubleshooting live API connectivity, I built a deterministic Demo Mode with predefined plant examples. It allows the rest of the application flow to be explored without relying on an external vision API, and it explicitly labels the examples as simulated.

The next engineering milestone is to integrate and validate an on-device biological vision model, evaluate its identification quality, and test the experience outdoors under limited or no connectivity.

Why Does Open Innovation Matter?

Nature does not wait for a good internet connection.

A trail can have no signal. A garden can be far from reliable connectivity. A curious student should not need a paid API subscription just to begin exploring the natural world.

That is why my long-term direction for NaturaDex is local-first, open-source AI.

An appropriately licensed, locally runnable biological vision model could help make nature discovery more private, more resilient to network failures, and less dependent on the availability or pricing of a hosted service.

Open innovation could also let contributors experiment with different models, improve identification for local species, evaluate failure cases, and adapt the application for different regions and ecosystems.

It is particularly important for a project like this because a model's mistakes can have real consequences. An incorrect plant identification could encourage unsafe handling or consumption. An open development process makes it easier to inspect the system, test its limitations, document uncertainty, and improve it collaboratively.

I want NaturaDex to become something people can run, understand, contribute to, and adapt — not just a thin interface around a service they cannot control.

I am not there yet. The current prototype still has a hosted vision-provider path, and the local BioCLIP-2 integration remains unfinished. But keeping the architecture modular gives me a practical path toward that goal.

The long-term vision is an open, offline-capable nature companion that helps people spend less time on screens and more time understanding the world around them.

My Agent Session

I used AI-assisted development to help plan the architecture, implement features, troubleshoot integration issues, and test the application.

I do not have a verified public DevRelay session link to share yet, so I am leaving this section without a fabricated link. If I publish a session later, I will add it here.

Prize Categories

I am submitting this as a project for the overall Touch Grass challenge. I am not claiming a partner prize category without a verified implementation of the relevant partner technology.

NaturaDex began with a question:

What if AI helped us pay more attention to the world instead of demanding more of our attention?

I am building toward that answer, one discovery at a time. 🌿

devchallenge #hf26challenge #opensource #ai #python #flask #nature

ShelfLife-KIMS

Ravindar Amogh Gummadavelly — Mon, 05 Oct 2026 02:52:02 +0000

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

What I Built

I built ShelfLife-KIMS, a smart kitchen management system that helps a household decide what to cook based on the people in the house, their food restrictions and preferences, and the ingredients they already have.

The main things I built are:

Household management — create a household and add different members.
Food profiles — store allergies, dietary restrictions, dislikes, preferred foods, spice level, texture, and cuisine preferences.
Inventory management — add ingredients, track quantities and expiry dates, edit or delete items, and record when food is consumed.
Food usage history — keep track of what ingredients were used and when.
Persistent storage — household and inventory data is stored using MongoDB Atlas, so it is not lost when the application reloads.
Web application — built a usable React frontend connected to a FastAPI backend.
Validation and safety — hard dietary restrictions are kept separate from soft preferences so important constraints are not treated like normal preferences.

The main idea behind ShelfLife-KIMS is: instead of just giving recipes, it understands the kitchen and the people in it.

Demo Video

https://drive.google.com/file/d/1m_gRI1GH9fyvkmLPbaghpoIYfXSmg-RU/view?usp=sharing

Deployed Link

https://shelflife-9tls.onrender.com/

Code

https://github.com/Ravindar-Amogh-Gummadavelly/ShelfLife-KIMS.git

How I Built It

I built ShelfLife-KIMS as a full-stack web application using React + TypeScript for the frontend and FastAPI + Python for the backend.

For the data layer, I used MongoDB Atlas to store household members, food profiles, inventory, and usage history.

For AI, the planned architecture is built around open-weight Gemma models with Mastra as the agent orchestration layer. The idea is that the AI acts as a kitchen brain that understands the household's constraints, preferences, and available ingredients instead of simply generating random recipes.

I also designed the system so that AI suggestions do not directly override important food restrictions. Hard constraints such as allergies and prohibited foods are handled deterministically by the application, while softer preferences can be used by the AI for ranking and recommendations.

The current deployed foundation focuses on making the household, food profiles, inventory, and persistence work reliably first, with the AI architecture designed to build on top of that foundation.

Why Does Open Innovation Matter?

Open innovation mattered because ShelfLife-KIMS was built to solve a real household problem by combining ideas, technologies, and data sources that would not be practical to build from scratch.

Using open APIs and tools made it possible to connect ShelfLife’s existing household and food data with intelligent recommendations, validation, and automation. A closed API would have limited us to whatever functionality one provider offered. Open innovation instead let us combine different capabilities and adapt them around the needs of the household.

Most importantly, it allowed us to build a more flexible product quickly—focusing our effort on the ShelfLife-KIMS experience and the problem we wanted to solve rather than reinventing infrastructure that already existed.

My Agent Session

Optional — no DevRelay agent session was saved for this project.

Prize Categories

Featured Categories

Best Use of Render

Partner Categories

Best Use of GitHub Copilot — if applicable based on the project's actual development history.
Best Use of MongoDB Atlas — if applicable based on the project's actual data layer.
Best Use of Sentry Agent Tracing — if applicable based on the deployed implementation.

Solo submission — no teammates to credit.

ShelfLife-KIMS started with a simple idea: food should be easier to manage before it becomes waste. We built it to bring household inventory, member preferences, and intelligent decision-making into one practical experience.

This project is more than a prototype—it is a foundation for a smarter, more sustainable way for households to manage the food they already have. By combining open innovation with a focused product experience, ShelfLife-KIMS turns everyday food management into something more predictable, personalized, and useful.

We built ShelfLife-KIMS with the belief that reducing food waste doesn't always require buying less—it can start with making better use of what we already have.