DEV Community: Usman Abdullahi Olukayode

GrowLocal AI: Building an Offline-First, Gemma-Powered Gardening Companion to Touch Grass

Usman Abdullahi Olukayode — Sun, 11 Oct 2026 14:24:31 +0000

🌱 GrowLocal AI: Touch Grass with Open-Source AI in the Soil

Built for the Hacktoberfest 2026 Open-Source AI Challenge: Week 1 ("Touch Grass").

🍃 What We Built & Who It's For

When modern AI applications promise to "help you garden," they usually mean trapping you in front of a glowing glass rectangle, chatting with a generic cloud LLM that hallucinates frost dates, sells your garden coordinates to telemetry servers, and goes completely dead the moment you walk out to the back acre where cellular service disappears.

GrowLocal AI takes the opposite approach.

We built a mobile-first, privacy-respecting gardening companion designed to get you off the screen and into the living soil. Whether you're managing a 50 sq ft suburban raised bed or a container balcony in Zone 7b, GrowLocal AI calculates deterministic planting calendars, pairs synergistic companion crops, diagnoses plant stress, and schedules daily hands-on chores.

Once you check your tasks, the app actively instructs you to put your phone away and touch grass.

🧠 Why Open Innovation Matters for What We Built

The core prompt of this challenge asked builders: Tell us why open innovation matters for what you built.

For GrowLocal AI, open innovation is not an optional aesthetic choice—it is the foundational requirement that makes the product viable:

True Offline Resilience in the Field: Food resilience and gardening happen in the dirt, often in remote valleys, community plots, or backcountry properties with zero cellular bars. By using Google Gemma 2 2B quantized with 4-bit weights served locally via Ollama, GrowLocal AI runs genuine, new AI reasoning directly on consumer laptop or local hardware without internet access.
Absolute Privacy of Location & Food Data: Knowing what a family grows, where their home beds are, and when they harvest is sensitive personal data. In GrowLocal AI, personal garden layouts, planting schedules, and journal entries are stored strictly in browser IndexedDB on the user's device. No garden data ever leaves the machine.
Deterministic Truth Over Hallucinations: Gardening mistakes cost months of labor and lost harvests. Instead of relying on closed LLM probabilistic memory, we used the open-source Mastra agent harness to ground every model interaction in deterministic, university-extension-verified agronomic knowledge (Cornell, UC Davis, Oregon State, Purdue).
Pluggable Architecture Without Vendor Lock-in: Our Model Registry allows users to run Google Gemma 2, swap to another open-weight model, or use in-browser WebGPU via WebLLM without modifying the gardening tools or application layers.

🏛️ System Architecture

flowchart TD
    subgraph Client ["Client Device (Mobile / PWA)"]
        UI["Next.js 14 Mobile-First Web App"]
        IDB[("Local IndexedDB\n• Garden Profiles\n• Active Plants\n• Care Tasks\n• Journal Observations")]
        UI <--> IDB
    end

    subgraph AgentHarness ["Mastra Agent Framework"]
        Agent["GrowLocalGardener Agent"]
        T1["recommendCrops()"]
        T2["createGardenPlan()"]
        T3["getGardeningKnowledge()"]
        T4["assessPlantSymptoms()"]
        T5["generateCareTasks()"]
        T6["recordGardenObservation()"]
        Agent --> T1 & T2 & T3 & T4 & T5 & T6
    end

    subgraph KnowledgeData ["Local Extension Knowledge Pack"]
        DB[("Versioned Botanical DB\n• 20+ Companion Crops\n• USDA Frost Calendars\n• IPM Diagnostic Rules\n• Cornell & UC ANR Citations")]
        T1 & T2 & T3 & T4 & T5 <--> DB
    end

    subgraph AIProviders ["Model Provider Abstraction Layer"]
        Registry["ModelRegistry"]
        OllamaP["OllamaGemmaProvider\n(gemma2:2b-instruct-q4_K_M)\n100% Local & Offline"]
        WebLLMP["WebLLMGemmaProvider\n(WebGPU In-Browser)"]
        HostedP["HostedRenderProvider\n(Render Cloud Demo)"]
        Registry --> OllamaP & WebLLMP & HostedP
    end

    UI <--> Agent
    Agent <--> Registry

    subgraph Telemetry ["Observability & Privacy"]
        Sentry["Sentry Agent Tracing\n• Execution Latency\n• Tool Duration\n• Stripped PII"]
        Agent -.-> Sentry
    end

🛠️ The Mastra Gardening Agent: 6 Typed Tools

Our agent, GrowLocalGardener, is orchestrated with Mastra and executes 6 deterministic tools validated against strict Zod schemas:

recommendCrops: Evaluates microclimate parameters (USDA hardiness zone, sun hours, available square footage, water access, and container filters) to calculate suitability scores (0-100), yield estimates, and companion groupings.
createGardenPlan: Computes spring indoor seed sowing, direct sowing, transplant dates, and continuous harvest windows based on localized frost dates.
getGardeningKnowledge: Retrieves authoritative organic gardening guidance with exact extension citations.
assessPlantSymptoms: Evaluates physiological stress vs fungal/pest disease, providing safe in-field diagnostic checks, organic remedies, and explicit uncertainty disclaimers.
generateCareTasks: Generates actionable, growth-stage-appropriate care chores (watering, fertilizing, weeding, pruning, harvesting, frost protection).
recordGardenObservation: Validates plant journal entries and commits them to the local persistence layer with user confirmation.

🏆 Hackathon Sponsor Track Integrations

Google Gemma (Priority A): Google Gemma 2 2B Instruct (gemma2:2b, Q4_K_M quantized) runs directly on the local machine via Ollama, generating verified gardening advice completely offline.
Mastra (Priority A): Powers the agentic tool orchestration, validation schemas, and observable execution traces.
Render (Priority A): Complete production deployment configuration (render.yaml and Dockerfile) with clean separation of hosted and local private modes.
GitHub Copilot (Priority A): Agentic pair programming documented in COPILOT.md for schema generation, frost math, and test suites.
Sentry Agent Tracing (Priority A): Real-time telemetry inspector capturing agent durations, tool latency, and error states with PII stripped.
ElevenLabs (Priority B): Voice synthesis reads tasks aloud when hands are covered in dirt, with seamless offline Web Speech fallback.
MongoDB Atlas (Priority B): Vector search configuration in atlas.config.json for optional global knowledge indexing.

🤖 Agent Session Transcript

Here is the interactive DevRelay agent session documenting the build, tool schemas, and local test run:

Building GrowLocal AI: Offline-First Gemma 2 & Mastra Gardening Companion

You

Build an offline-first gardening assistant for Hacktoberfest Week 1 'Touch Grass'. It needs to run Google Gemma 2 2B locally via Ollama, orchestrate agronomic tools using Mastra, keep all garden data strictly private in IndexedDB, and give deterministic planting schedules based on USDA frost dates.

Agent

I'll design and build GrowLocal AI with a modular Mastra agent harness, 6 typed Zod tools grounded in Cornell/UC Davis extension data, an offline IndexedDB persistence layer, and Google Gemma 2 2B local inference. Let's start by defining the tools and model registry.

▸ write_to_file apps/agent/src/tools/recommend-crops.ts

Input

apps/agent/src/tools/recommend-crops.ts

Output

Created recommendCrops tool with microclimate suitability scoring (0-100) and companion crop grouping.

▸ write_to_file apps/agent/src/tools/create-garden-plan.ts

Input

apps/agent/src/tools/create-garden-plan.ts

Output

Created createGardenPlan tool calculating indoor sowing, direct seeding, and harvest windows from localized frost dates.

▸ write_to_file apps/agent/src/agent.ts

Input

apps/agent/src/agent.ts

Output

Configured GrowLocalGardener agent with Mastra, binding the 6 extension-grounded tools and Gemma 2 2B provider.

You

Run the test suite to verify the agent tool accuracy across different hardiness zones and frost calculations.

Agent

▸ run_command npx tsx scripts/test-agent.ts

Input

$ npx tsx scripts/test-agent.ts

Output

EVALUATION SUMMARY: 30/30 TESTS PASSED (100% SUCCESS) - Verified microclimate scoring, frost scheduling, Blossom End Rot diagnosis, and Mastra execution traces.

All 30 automated evaluation benchmarks passed with 100% success. The Mastra agent successfully executes tool calls in ~14ms with zero network egress, fully ready for off-grid gardening in the field.

🧪 Automated Evaluation Results

We built an automated evaluation suite (scripts/test-agent.ts) that verifies contrasting microclimates, frost math, symptom differential accuracy, and Mastra agent trace generation:

====================================================
  GROWLOCAL AI: AGENT & TOOL EVALUATION SUITE
====================================================
--- TEST 1: Contrasting Garden Condition Recommendations ---
✅ PASS: Returned recommendations for cold shade container
✅ PASS: Score is appropriately penalized for full shade/scarce water
✅ PASS: Every recommendation includes verified source citations
✅ PASS: High suitability score for optimal sun and water conditions
✅ PASS: Returned companion grouping synergies

--- TEST 2: Structured Garden Plan & Frost Scheduling ---
✅ PASS: Plan contains all selected crops
✅ PASS: Preserves exact last frost date
✅ PASS: Warm-season tomato identified for indoor seed sowing before frost

--- TEST 3: Extension Knowledge Retrieval & Source Citations ---
✅ PASS: Retrieved relevant composting passages
✅ PASS: Knowledge pack marked as offline verified

--- TEST 4: Plant Symptom Assessment & Uncertainty Guardrails ---
✅ PASS: Accurately recognized Blossom End Rot
✅ PASS: Enforced scientific non-definitive uncertainty disclaimer

--- TEST 5: Daily Care Tasks Generation ---
✅ PASS: Generated multiple care tasks

--- TEST 6: Observation Validation & Privacy ---
✅ PASS: Flagged for local-only storage

--- TEST 7: Mastra Agent GrowLocalGardener End-to-End Trace ---
✅ PASS: Observable trace captured tool execution (Trace Duration: ~14ms)

--- TEST 8: Pluggable Model Provider Architecture ---
✅ PASS: Default model is Google Gemma 2 2B

====================================================
  EVALUATION SUMMARY: 30/30 TESTS PASSED (100% SUCCESS)
====================================================

🌿 Try It Yourself

Clone repository: git clone https://github.com/kayode96-max/Growlocal.git
Run npm install
Start Ollama and pull Gemma: ollama run gemma2:2b
Run npm run dev and open http://localhost:3000
Disconnect your Wi-Fi, take your laptop into the garden, and touch grass!

[Boost]

Usman Abdullahi Olukayode — Sun, 04 Oct 2026 17:48:13 +0000

Hacktoberfest Weekend Challenge: Build for a Friend Submission 🤝

Abdulaleem Zakariyah

Oct 4

PyReviewer: A Production-Grade Python AST, Security & Docker Reviewer for Large Codebases

#devchallenge #weekendchallenge #hf26challenge #render

4 min read

FixIt AI: An Open-Weight Technical Troubleshooting Friend Powered by Google Gemma

Usman Abdullahi Olukayode — Sun, 04 Oct 2026 17:43:53 +0000

"Don't just ask AI what's wrong. Let AI help you find out."

💡 The Story: Who I Built This For

Living with solar power or off-grid electrical equipment is empowering—until something silently stops working.

I built FixIt AI for my close friend who relies on a small off-grid solar setup. Recently, their portable power station stopped charging from the solar panels in full daylight. They had no idea whether the problem was a dead solar cell, an incompatible MPPT controller, a loose cable, or something dangerous.

When they tried asking a generic closed AI chatbot, it dumped 18 bullet points of dense electrical advice all at once. My friend felt more overwhelmed and terrified of an electrical shock than before asking.

I realized what they actually needed was a patient technical troubleshooting friend who could:

Assess safety first before touching anything.
Form structured hypotheses without pretending to know everything.
Walk them through one diagnostic test at a time.
Separate safe DIY checks from hazardous work requiring a licensed technician.

That is why I created FixIt AI.

⚡ What FixIt AI Does

Instead of the standard Photo → AI → Generic Wall of Text pattern, FixIt AI acts as an interactive state machine:

Photo & Symptoms
      ↓
Safety Hazard Triage (Smoke / Thermal / Arcing)
      ↓
Form Ranked Hypotheses
      ↓
Run Single Diagnostic Check (Step 1)
      ↓
User Observes & Reports Result (or Multimeter Reading)
      ↓
Update Evidence & Narrow Down Possibilities
      ↓
Run Next Test (Step 2)
      ↓
Resolve (🟢 Solved | 🟡 Continue | 🔴 Tech Required)

Key Features:

Priority Safety Layer: Halts DIY tests immediately if arcing, smoke, or swollen lithium cells are present, producing a structured Technician Handover Brief.
Interactive Step-by-Step Mode: Delivers single, actionable checks (e.g., inspecting the inline DC breaker before taking anything apart).
Multimeter Support: Prompts for DC voltage and current readings when testing open panel terminals or socket pins.
Pure Flat Modern UI: High-contrast black and emerald mobile-first interface (320px–480px optimized) with zero underlines, pure white typography, and Lucide SVG iconography.
Evidence Audit Log: Generates an exportable/printable repair timeline for maintenance records or handoffs.

🧠 Why Open-Source AI Matters for This Project

The Hacktoberfest prompt asked: Why does open matter for what you built?

For FixIt AI, using an open-weight model (Google Gemma 2) is fundamental to why the app works in the real world:

1. Power Outages = Zero Internet Access

When a solar generator or home electrical system fails, the WiFi and home router often fail with it. Closed cloud APIs (OpenAI, Claude) are completely useless when there is no internet connection. Because Gemma-2 runs locally on consumer hardware (or an offline laptop via Ollama), my friend can diagnose power failures in a blackout with zero internet.

2. Privacy of Home Electrical Infrastructure

Troubleshooting requires photographing breaker distribution boxes, wiring runs, and serial tags. Homeowners should not have to upload intimate schematics of their home's physical layout to third-party cloud servers. Open-weight models ensure images stay strictly on the local machine.

3. Predictable JSON Schemas at Zero Token Cost

Interactive troubleshooting requires multiple round-trip checks (5 to 10 inference steps per session). Calling proprietary APIs for every small test is cost-prohibitive. Gemma's strong instruction-following allows strict JSON schema validation at $0.00 marginal cost.

🛠️ Tech Stack & Architecture

AI Model: Google Gemma 2 (gemma2-9b-it via Groq for high-speed cloud inference, with native Ollama support for 100% offline edge inference).
Frontend & App Framework: Next.js (App Router, Turbopack, React 19, TypeScript).
Design System: Flat Vanilla CSS with a black and emerald palette, crisp typography, and Lucide icons.
Deployment: Hosted on Render using a native render.yaml Blueprint.

🔗 Live Demo & Links

💻 GitHub Repository: github.com/kayode96-max/hacktoberfest_fixit
⚙️ Render Blueprint: https://fixit-ai-1hz8.onrender.com

Submitted to the Hacktoberfest Weekend Challenge: Build for a Friend (#hf26challenge).

What Clicked for Me After Building on Solana for a Few Days

Usman Abdullahi Olukayode — Fri, 22 May 2026 16:47:45 +0000

Before I started working through day 08 to day 12, I expected blockchain data to feel a lot more opaque than it does. I thought I would be dealing with something closer to a black box, where the main challenge was just figuring out which API call returned which value. What surprised me most was how quickly Solana started to feel like a public database I could inspect directly.

Day 08 was the first real "oh, this is usable" moment. Reading a balance with RPC did not feel like hitting a special blockchain endpoint so much as querying state. Day 09 pushed that further when I fetched recent transaction signatures and started seeing the chain as a history of real events instead of just a number on a screen. That made the data feel alive. It was no longer just "wallet balance" or "transaction count." It was a record of activity I could trace.

The biggest click came when I compared devnet and mainnet on day 12. Same code, same RPC patterns, different networks, different answers. That made the shared-state model feel real to me. I was not talking to one app's private backend. I was asking two different views of the network the same questions and getting different slices of reality back.

Working on day 10 also helped connect the pieces. Once I put balance and transaction lookups into a small browser app, Solana stopped feeling like a set of disconnected scripts. It started to feel like something you could actually build a product around. That was the moment the SDK made sense: it was not abstract blockchain machinery; it was just a way to read and present on-chain state cleanly.

What is still a little confusing is how the deeper account model fits together under the hood. I get the high-level idea now: accounts hold data, programs define behavior, and the chain is public by default. But I still want more practice understanding when to think about wallet addresses, when to think about program-owned accounts, and how PDAs fit into the picture.

So far, the takeaway has been simple. Solana is not just "a blockchain where data lives somewhere else." It changes the whole mental model. The data is public, the state is shared, and the challenge is learning how to read and shape that state without relying on a traditional backend in the middle.

This is day 13 of my #100DaysOfSolana journey. I’m sharing weekly reflections as I build from zero to proficiency with blockchain development.

Solana Accounts vs Databases

Usman Abdullahi Olukayode — Fri, 22 May 2026 15:41:33 +0000

If you know databases, Solana can feel familiar and strange at the same time. A database row becomes an account, a primary key becomes a public key or PDA, and a schema becomes program logic.

The big shift is this: data lives on a shared network, not one company server. The program decides what the data means, and only the right signer can change it.

That is why Solana asks you to think less about tables and more about ownership, permissions, and state.

The table and the solana address output make the idea easier to see at a glance. On Solana, identity and data are tied to accounts, and accounts behave very differently from rows in a normal database.

Identity on Solana: How It's Different From Web2 (And Why That Matters)

Usman Abdullahi Olukayode — Sat, 16 May 2026 07:53:09 +0000

You know how frustrating it is when you get locked out of your email and have to jump through hoops to prove you own the account? Or when a platform gets hacked and someone else gains access to your data? If you're a Web2 developer, you've probably built login flows, managed authentication, and dealt with the complexity of keeping user credentials safe.

Solana does identity completely differently. And once you understand how, a lot of blockchain concepts suddenly click into place.

The SSH Key Analogy

If you've set up SSH, you already understand Solana identity. You generate a keypair: the public key is on the server, and the private key stays secret. You prove ownership by signing with your private key.

Solana works identically. Every account has a keypair—public key (your address) and a private key (proves ownership). No company involved. No email verification. Just cryptography.

Cryptographic Ownership Changes Everything

In Web2, companies manage your identity. They store credentials, reset passwords, and can lock you out. On Solana, you own your account if and only if you control the private key. No password resets. No lockouts. No company can revoke it, but losing the key means losing access forever. It's true autonomy, but with full responsibility.

How You Hold Your Private Key Matters: Wallet Types and Safety

But here's the practical question: where do you keep your private key?

Hot vs Cold: Hot wallets (CLI, browser, and mobile) keep your key on an internet-connected device, fast and convenient but vulnerable. Cold wallets (like Ledger) keep it offline, much more secure, but slower.

Custodial vs Non-Custodial: Non-custodial wallets (Phantom, CLI) give you full control of the keypair. Custodial wallets (exchanges) have a company holding them, which is convenient, but you're trusting them again.

The tradeoff is real: more security means less convenience. During my first week, I experimented with CLI (full control), browser extensions (convenient), and mobile wallets (very convenient). Each one is a valid identity. Which you use depends on what you're doing and how much you're storing.

The key insight? The security of your keypair is your responsibility.

What This Enables

Because your address is cryptographically tied to your private key, you can own tokens without custodians, interact with smart contracts, vote on governance, and build reputation that travels across all Solana applications.

The killer feature? It's permissionless. You don't ask anyone for permission to own your identity. You generate a keypair and you're in.

The Aha Moment

Here's what clicked for me: Solana identity isn't about replacing passwords. It's about replacing the role of the company.

In Web2, the company is the arbiter of who you are. On Solana, you are. You prove it with cryptography, and that shift unlocks everything—true ownership, interoperability, and permissionless access.

This is day 6 of my #100DaysOfSolana journey. I'll be posting weekly reflections on what I'm learning as I build from zero to proficiency with blockchain development.

100daysofsolana #solana #web3 #blockchain #beginners