This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass We build AI tools to help us do more on our screens. But what if we built one that encouraged us to put the phone down?
That question inspired WILDR, an offline-first AI nature companion designed to turn an ordinary walk into an opportunity to explore, observe, and learn.
WILDR is designed for curious beginners, students, nature enthusiasts, and anyone who wants to reconnect with the world beyond their screen.
The idea is straightforward: use technology to prepare for an outdoor experience, then let the real world take over.
🌿 Outdoor discovery missions: Find different leaf shapes, observe pollinators, explore habitats, or listen for bird sounds.
📷 AI-powered image identification: Photograph an observation and use a local image model to explore possible classifications, without sending the image to a hosted AI service.
📓 An offline field journal: Save observations, notes, and identification results locally so discoveries can be revisited later.
📴 Offline-first by design: After the necessary app resources and model have been downloaded, the core experience is intended to work without an internet connection.
WILDR isn't meant to become another app that demands constant attention. It should help users discover something interesting, then give them a reason to look up from their phones.
**Live demo:** [URL]
**Video walkthrough:** [URL]
The planned demo will show the complete experience: selecting an outdoor mission, identifying a photograph with local AI, saving the observation, and accessing the journal while offline.
The live demo and video links will be added once deployment and offline verification are complete.
GitHub repository: https://github.com/gene707/WILDR The project is being developed as a responsive Progressive Web App using React, TypeScript, and Vite.
The planned architecture includes:
The goal is to make the project understandable, reproducible, and open to contributions rather than hide its core functionality behind a proprietary service.
I approached WILDR as a sequence of engineering milestones instead of trying to build everything at once.
1. Build the experience first.
The foundation is a mobile-friendly interface with separate spaces for discovering missions, identifying images, and recording observations.
2. Make the outdoor activities useful on their own.
Missions are structured pieces of content, not AI-generated filler. They should remain accessible even when the user has no internet connection.
3. Bring AI onto the device.
The image-identification component is designed around a compact model that can run locally through ONNX Runtime Web and WebAssembly. This avoids making a remote inference API a requirement for the core experience.
4. Make offline operation a real requirement.
Caching a homepage is not enough. The intended acceptance test includes reopening the app without a network connection, completing a mission, running local inference, and saving an observation.
5. Verify before making claims.
Model licensing, image-classification performance, storage behavior, and offline compatibility need to be tested and documented. A model's prediction is a suggestion, not a definitive species identification.
The implementation is being organized into six milestones: foundation, missions and journal, local AI, offline PWA support, feature integration, and release verification.
For me, open innovation is about more than making source code publicly available. It is about being able to inspect, understand, adapt, and improve the technology behind a product. WILDR's local-first approach makes that especially important.
Privacy becomes an architectural decision. When inference runs on the device, a photograph does not need to be uploaded to a remote AI provider just to generate a prediction.
Connectivity becomes less of a barrier. Someone exploring a park, garden, or trail should not need a reliable connection every time they want to use the app.
The community can improve the project. Contributors can review the model integration, suggest better mission content, improve accessibility, test different devices, and help evaluate more appropriate nature-specific models.
The AI can be examined instead of treated as a black box. Documented model weights, label sets, and evaluation results help contributors understand what the system can and cannot recognize.
There is an important distinction here: open-source code does not automatically make pretrained model weights or training datasets freely redistributable. Verifying those licenses is part of building WILDR responsibly.
A closed API might offer a quick route to a prototype, but it would not provide the same degree of control over local inference, data handling, and model integration.
I am using AI coding tools to help implement the project in small, verifiable milestones. The aim is not simply to generate code quickly, but to inspect the implementation, run tests, and validate the important claims.
[Add the applicable partner prize categories from the official challenge rules.]
I will select the categories that match the final implementation and the challenge's eligibility requirements.
Technology doesn't always need to keep us connected to a screen. Sometimes, it can help us notice what we were missing while looking at one.
With WILDR, I want to explore how open-source AI can make that possible: not by replacing curiosity with automated answers, but by giving people a small nudge toward the world around them.
If you could build one AI-powered tool that encouraged people to spend more time outdoors, what would it help them discover?