DEV Community: DaKaufeeBoii

The Gardening Assistant: Using Open-Weight AI to Get Out of the House 🌱

DaKaufeeBoii — Mon, 12 Oct 2026 07:02:57 +0000

What I Built:

As developers, we spend a ridiculous amount of time staring at screens. We build applications to solve problems, automate tasks, and make life easier, but sometimes we forget to step away from our desks and actually experience the world outside.

That got me thinking: What if AI could help us spend less time on our screens instead of finding more reasons to stay on them?

Meet The Gardening Assistant (TGA), an AI-powered gardening planner built for the Hacktoberfest 2026 Touch Grass challenge.

TGA helps users figure out what to grow based on their available sunlight, garden type, experience level, and available space. Instead of dumping a massive list of plants and expecting beginners to figure everything out, it creates a personalized gardening plan with three targeted plant recommendations, care instructions, and an actionable four-week outdoor checklist.

But the most important feature isn't the AI itself. It's what happens after the AI finishes its job.

Every recommended plant comes with a hands-on outdoor activity, from pruning stems to crushing mint leaves and observing morning blooms. The weekly checklist encourages users to spend approximately 15–25 minutes outdoors per session, turning gardening from an overwhelming hobby into something manageable.

Here's what TGA offers:

Personalized plant recommendations: Find plants suited to your sunlight, available space, gardening experience, and garden type.

Practical care guidance: Get watering schedules, growing-cycle information, and companion-planting tips.

Touch Grass activities: Turn recommendations into real-world sensory experiences and gardening tasks.

A four-week action plan: Follow weekly tasks, track your progress, and build a consistent gardening habit.

Progress tracking: Save completed tasks locally in your browser.

A fallback recommendation engine: Continue generating garden plans even when the local AI model is unavailable.

The philosophy behind TGA is simple: The screen should be the shortest part of gardening.

Demo

Explore the source code: The Gardening Assistant on GitHub

The repository includes the implementation, architecture documentation, screenshots, and setup instructions.

The project is designed to run locally. Follow the README to start the frontend and backend and explore the gardening planner.

Code

Check out the complete repository:

github.com/DaKaufeeBoii/The-Gardening-Assistant

The project is organized into a React frontend, a FastAPI backend, and a curated botanical dataset.

The recommendation flow looks like this:

The user provides their gardening conditions.

The frontend sends the garden profile to the backend.

The backend evaluates suitable plants using curated botanical information.

Gemma personalizes the recommendations when local inference is available.

The application returns a structured garden plan and generates actionable outdoor tasks.

The user tracks progress directly in the browser.

The important design decision here is that the model isn't expected to invent everything from scratch. The botanical dataset provides factual grounding, while a deterministic recommendation engine provides a reliable alternative when the model isn't available.

How I Built It

The main challenge was figuring out how to use AI meaningfully without making the entire application dependent on an AI API.

Here's the stack behind TGA:

Frontend: React 19 and Vite, with a custom CSS design system and Lucide icons.

Backend: Python, FastAPI, and Pydantic for API handling and validation.

AI model: Google's open-weight Gemma model, running locally through Ollama.

Knowledge base: A curated JSON dataset containing plant information, sunlight requirements, watering frequencies, and climate notes.

Recommendation engine: A rule-based scoring system that evaluates sunlight compatibility, space constraints, gardening experience, and garden type.

Persistence: Browser localStorage for saving the generated plan and checklist progress.

Why Gemma?

For this challenge, I wanted AI to be useful without requiring every user to send personal information to a remote inference service.

TGA uses Gemma through local Ollama inference, with support for models such as gemma:2b and gemma2:9b, depending on the available hardware and configuration.

The model receives curated plant facts alongside the user's gardening conditions. This gives it a grounded starting point for producing personalized recommendations rather than relying entirely on whatever it generates from its parameters.

And if Ollama isn't running? The deterministic botanical recommendation engine takes over.

That hybrid approach matters because a gardening assistant should still be useful when an AI model is unavailable. A broken model connection shouldn't prevent someone from figuring out what to plant.

Designing for the Real World

Another important decision was keeping the application focused on action rather than engagement.

The four-week checklist gives users a clear sequence of tasks they can follow away from their computers. It also supports progress tracking, so users can return to the application when they need guidance without having to remain online throughout the activity.

The result is an application where AI helps plan the experience, but the actual experience happens outdoors.

Why Does Open Innovation Matter?

Open innovation made it possible to build TGA around a different idea of what an AI-powered application should look like.

Using an open-weight model such as Gemma gives developers the freedom to experiment with local inference, inspect the surrounding application architecture, customize prompts, and choose how and where inference happens.

For TGA, this creates three practical advantages.

More control over privacy

Garden profiles can include information about someone's home, available outdoor space, and personal habits. Running inference locally allows the application to personalize recommendations without sending that profile to a remote model provider.

Less dependence on external AI services

Local inference avoids requiring a paid hosted-model API for the core recommendation workflow. It does require suitable local hardware and a working model installation, which is why the rule-based fallback is important.

More freedom to experiment

The model, botanical dataset, and recommendation engine can be developed and improved independently. Developers can adjust the plant data, change the model configuration, refine the scoring rules, and contribute improvements without rebuilding the entire application around a proprietary service.

Open innovation isn't just about using something free. It's about having the ability to understand, adapt, and build upon the technology you're using.

TGA is a small example of what that freedom makes possible.

My Agent Session

TGA combines model-assisted recommendations with a deterministic fallback rather than relying on an autonomous agent to control the entire workflow.

The main flow is straightforward:

Garden profile → Botanical grounding → Gemma inference or rule-based fallback → Personalized plan → Outdoor action checklist

This keeps the model's role focused and makes the recommendation process easier to reason about.

Prize Categories

Best Use of Gemma: Local, open-weight AI inference combined with curated botanical knowledge and a deterministic fallback.

Best Use of ElevenLabs: Planned voice narration for hands-free gardening guidance, with browser speech synthesis as a fallback.

Best Use of SerpApi: Planned real-time frost-date research to improve planting recommendations.

Best Use of Sentry Agent Tracing: Backend observability for inference latency, token usage, and fallback events.

The core implementation centers on Gemma. The additional integrations are intended extensions of the project and should be evaluated against their actual configuration and working state.

Building TGA reminded me that AI doesn't always need to help us do more things on a screen. Sometimes, its best use is helping us decide what to do after we close the laptop.

Now, time to touch grass.

Repository: The Gardening Assistant (TGA)

Hacktoberfest #OpenSource #Gemma #AI #Gardening #TouchGrass

Heirloom — Preserving the Recipes We Don't Want to Lose

DaKaufeeBoii — Mon, 05 Oct 2026 06:58:55 +0000

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

What I Built

I built Heirloom, a voice-first family recipe and memory archive designed for someone close to me.

The idea came from a simple problem: some of the most meaningful family recipes aren't written down. They're passed from one person to another through stories, conversations, and instructions like:

"Add a little more until it looks right."

That works when you're standing in the kitchen with someone who has made the dish a hundred times.

It doesn't work when you want to preserve that recipe for the next generation.

Heirloom turns those informal recipe memories into structured, reusable recipes while preserving the story and context behind them.

Instead of forcing someone to manually type ingredients, measurements, and instructions, they can describe the recipe naturally using their voice. AI processes that conversation and extracts the useful information into a structured recipe.

The result isn't just a recipe database.

It's a way of preserving the people, stories, and traditions attached to food.

Demo

Live Demo: https://heirloom-9trv.onrender.com

Code

GitHub: https://github.com/DaKaufeeBoii/Heirloom

How I Built It

Heirloom combines voice AI, an open-weight language model, persistent storage, observability, and a web application into a single pipeline.

The core flow looks like:

Voice → transcription → Gemma → structured recipe → MongoDB Atlas → searchable family archive

Gemma

The intelligence behind the recipe extraction is Gemma, Google's open-weight model.

I use Gemma to understand unstructured descriptions and extract information such as:

Ingredients and quantities
Preparation instructions
Cooking steps
Timing
Serving information
Important cooking details that might otherwise be lost
The story and context associated with the recipe

Using an open-weight model was important because the application is fundamentally about preserving personal memories. It gives me more control over how the AI is used and makes it possible to experiment with different deployment and inference setups.

ElevenLabs

ElevenLabs powers the voice side of the experience, allowing Heirloom to work naturally with spoken memories rather than requiring everything to be typed.

This makes the application feel much closer to the way family recipes are actually passed down: through conversation.

MongoDB Atlas

MongoDB Atlas is the application's data layer.

Recipes, memories, and their associated structured information are stored in Atlas so they can become a persistent personal archive rather than disappearing after a single AI interaction.

Render

The application is deployed on Render, which hosts the live application and makes Heirloom accessible through the public demo.

Sentry

I also integrated Sentry Agent Tracing to understand what the AI pipeline is actually doing.

This gives me visibility into the agent's execution, including where time is being spent and where failures occur, instead of treating the AI as a black box.

That was particularly useful while iterating on the recipe-processing pipeline.

Why Does Open Innovation Matter?

Heirloom deals with something personal: family memories.

That makes it important to have control over the AI layer.

Using an open-weight model like Gemma means the application isn't fundamentally locked into one proprietary model provider. I can experiment with different inference environments, prompts, model versions, and deployment strategies as the project evolves.

That matters because the long-term goal isn't just to generate recipes.

It is to build a system that can understand the way real people describe food — including incomplete measurements, regional terminology, family-specific shortcuts, stories, and instructions that don't look anything like a conventional recipe.

Open models make that experimentation possible.

They also make the project more adaptable: the model can potentially move closer to the user and their data rather than requiring every interaction to depend on a closed API.

For a project about preserving personal memories, that control is valuable.

My Agent Session

I built Heirloom using an agent-assisted development workflow and used Sentry tracing to inspect the AI workflow and understand how the application was behaving during development.

Prize Categories

Featured Categories — $200

Best Use of Render

Heirloom is deployed on Render and uses it to host the live application.

Best Use of Gemma

Gemma is the open-weight model at the core of Heirloom's AI recipe-understanding workflow.

Partner Categories — $100

Best Use of ElevenLabs

ElevenLabs powers the voice interaction/transcription component of Heirloom.

Best Use of MongoDB Atlas

MongoDB Atlas serves as Heirloom's persistent data layer for storing recipes and memories.

Best Use of Sentry Agent Tracing

Sentry is integrated into the AI workflow to trace agent execution and help inspect performance and failures.

Built for a Person, Not a Prompt

The easiest way to build an AI project is to start with the technology:

"What can this model do?"

I started with a different question:

"What is something someone I care about might actually lose?"

The answer was memories.

A recipe can be recreated.

A list of ingredients can be searched online.

But the way someone explains their recipe, the little rules they never write down, and the story behind why that dish matters are much harder to replace.

That's what Heirloom is trying to preserve.

Not just the recipe.

The person behind it.

Building HemoConnect: An AI-Powered Companion for Thalassemia Management

DaKaufeeBoii — Sun, 12 Jul 2026 13:30:39 +0000

When managing a chronic condition like Thalassemia, patients and their caregivers often face a fragmented healthcare experience. From tracking down blood availability in emergencies to decoding complex medical reports, the cognitive load is immense.

Our team, TechMonsters, is set out to bridge this gap.

The result is HemoConnect—a unified, AI-powered platform designed to provide real-time resources, personalized health insights, and a supportive community. Here is a deep dive into how we built it, the tech we used, and the hurdles we overcame.

The Problem we Solved

Thalassemia management requires continuous, lifelong care, primarily centered around blood transfusions and monitoring iron levels. We identified three major pain points in the current ecosystem:

Emergency Blood Sourcing: Finding compatible blood during shortages is highly stressful and relies heavily on disjointed social media posts or calling multiple blood banks.
Medical Jargon: Lab reports (like ferritin levels or hemoglobin counts) are difficult for the average patient to interpret contextually.
Isolation: Patients lack a centralized, safe space to connect, share experiences, and access verified care directories.

HemoConnect solves this by acting as a single hub featuring a real-time Blood Order system, a Care Directory, a Community forum, and an AI-driven Report Analysis & Chatbot Assistant.

Tech Stack & Partner Tracks

To build a responsive, scalable, and intelligent platform within a strict time crunch, we carefully selected a modern full-stack and AI architecture.

Frontend: React. We needed a snappy, interactive user interface for the main Dashboard and seamless navigation between the community and care tools.
Backend & Database: Supabase / Firebase. This handled our authentication and the real-time database syncing required for the live Blood Order feature and Community forums.
AI & Machine Learning: Python. We built a custom Retrieval-Augmented Generation (RAG) system to power the context-aware Chatbot Assistant and the Report Analysis engine.
Partner Tracks used: Made using Base44 Planning on using Sarvam AI for Voice Chat features (WIP).

Implementation Deep Dive

The core of HemoConnect lies in how its features interact to create a holistic user experience.

The Context-Aware Chatbot & Report Analysis
The standout feature of HemoConnect is its intelligence. Instead of a generic bot, we implemented a sophisticated RAG architecture. Users can upload their latest medical reports, and the Report Analysis tool processes the data, breaking down complex metrics into understandable insights. The Chatbot Assistant is highly context-aware, meaning it remembers the user's specific health data from the reports and answers follow-up questions accurately, acting as an always-on digital health companion.
Real-Time Blood Ordering
Time is of the essence when a transfusion is needed. We built a real-time pipeline where the Blood Order page syncs directly with our backend database. This allows users to request specific blood types and see availability instantly, drastically reducing the time spent searching during critical moments.
Community & Care Directory
Health is as much about mental support as it is physical. The Community page provides a forum-like experience for users to connect. Alongside this, the Care Directory acts as a verified list of specialists, clinics, and resources tailored specifically for Thalassemia care.

Challenges we faced

Building a health-tech MVP in a highly compressed timeframe brought several significant challenges:

Preventing AI Hallucinations in Healthcare Data: When dealing with medical reports, the AI cannot afford to guess. Fine-tuning our RAG system to strictly anchor its responses to the provided medical context (and safely stating when it didn't know an answer) required intensive prompt engineering and data structuring.
Real-Time Data Syncing: Ensuring that the Blood Order feature updated concurrently for all users without lag or database locking issues was tricky. We had to carefully optimize our backend listeners to handle concurrent read/write requests efficiently.
UI/UX for Accessibility: Designing a dashboard that houses complex AI tools, community forums, and emergency features without overwhelming the user took several iterations. We focused heavily on a clean, card-based layout to keep the cognitive load as low as possible.

Conclusion & Future Scope

Building HemoConnect was an incredible sprint of coding, debugging, and learning. It reinforced how powerful modern web frameworks and context-aware AI can be when directed at real-world healthcare problems.

Looking forward, we want to expand HemoConnect by integrating direct APIs with local blood banks for automated inventory tracking and adding predictive analytics to warn users of potential iron overload based on their historical report data.

Acknowledgements & HackHazards '26

This project was built as part of HackHazards’26, beautifully organized by Namespace. Competing and building under pressure is always an incredible experience, but it wouldn't be possible without the right backing.

We want to extend a massive thank you to the event sponsors for their support and for providing the developer tools that powered our build. A very special shoutout to Base 44 for their incredible backing, along with huge thanks to Expo, Sarvam, and Neo4j for helping make this event and our project a reality!

Check out the live project here.