Submission for the GitHub Finish-Up-A-Thon Challenge
Mango farming is a lifeline for millions of smallholder farmers in Ethiopia.
A single fungal outbreak can silently destroy 20–30% of a harvest before a
farmer even recognises it. Existing solutions require a lab, a specialist,
or reliable internet. None of those exist where the problem is worst.
MangoGuard runs AI directly on a microcontroller smaller than a credit card
— no cloud, no Wi-Fi, no lab.
An Arduino Nano 33 BLE Sense runs a quantized MobileNetV1 model that
classifies mango leaf disease in under 2 seconds at 86.45% accuracy on real
Ethiopian farm data. The Nano also reads live temperature and humidity via a
DHT22 sensor and sends everything — disease result, temp, and humidity — to a
Raspberry Pi 4 gateway, which evaluates environmental disease risk against
agronomic thresholds, runs a 24-hour AI forecast model, and generates
plain-language recommendations pushed directly to farmers based on current
conditions.
Everything streams to a React dashboard in real time via WebSocket.
From the dashboard you can:
- Monitor live environmental readings and disease risk
- Run a cloud scan from your phone — upload any leaf photo for instant AI classification, no hardware required
- View a 5-day disease risk forecast calendar
- Browse your full scan history in the logs section
The dashboard is fully bilingual — English and Amharic (አማርኛ) — because
agronomists advising Ethiopian farmers shouldn't have to work in a language
that isn't theirs.
Under the hood, every scan is saved to a PostgreSQL database. The admin
dashboard exposes this data as a labeled dataset that can be used to
retrain and improve the model over time as more field data comes in.
🌐 Live Demo: https://mango-guard.vercel.app/
📂 GitHub: https://github.com/SCIFI-Shinobi/Intelligent-Mango-Health-Monitoring
The Comeback Story
The hackathon prototype worked — but only on my machine, with undocumented
secrets, and no way for anyone else to run it. Here's what I shipped to fix that:
- Rewrote the README from scratch — setup guide, env variable reference, troubleshooting for the 7 most common failures
- Added
ARCHITECTURE.md,DEPLOYMENT.md, andCONTRIBUTING.md - Fixed
.gitignorewhich was blocking.env.examplefiles from being committed - Documented all 10 required environment variables (previously scattered in source code)
- Added GPL-3.0 LICENSE — the repo had no legal clarity before
-
Fixed a real production bug — I had set scan intervals to 20 seconds
and forecast to trigger after 3 readings for demo convenience. The forecast
model was actually trained on a 24-reading window (one per hour). In the
field it was producing numbers that looked valid but weren't. Fixed:
scanIntervalMs = 3600000UL, forecast threshold ≥ 24.
A stranger can now fork, configure, and deploy this in under 20 minutes.
Copilot Experience
Copilot saved the most time on the backend — main.py grew past 3,000 lines
and it was excellent at continuing repetitive patterns: email templates,
database migration helpers, route structure. Once I wrote the first, it nailed
the second.
During the polish phase, asking Copilot to review the README flagged that I
had no troubleshooting section and no env variable docs — exactly what a
first-time contributor needs. It also helped clean up firmware comments after
I fixed the production bug.
It spotted multiple ESLint warnings, duplicate translation keys, and unused imports/variables that were silently compiling locally but completely blocking production builds on Vercel CI.
The honest limitation: it continues patterns well but won't proactively tell
you what's missing. You have to ask the right question first.
Built to bridge the gap between AI and smallholder agriculture in Ethiopia. 🌱
Top comments (0)