This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
What if AI's most useful output wasn't another answer on your screen, but a reason to step away from it?
We have built AI tools that write, summarise, code, plan, and answer almost any question. But what if we used AI to help us spend a little less time looking at screens?
That question led me to build OutsideIn, a local-first nature exploration companion created for the Hacktoberfest 2026 Open-Source AI Challenge.
The theme is simple: Touch Grass.
OutsideIn turns a few minutes outdoors into a small adventure. It uses AI to suggest things to observe in a garden, park, college campus, or neighbourhood, encouraging people to notice the world around them rather than endlessly scroll through it.
The idea: make going outside the shortest part of using an app
Not every outdoor experience needs a complicated itinerary, expensive equipment, or an entire free afternoon.
Sometimes, all you need is a little curiosity.
With OutsideIn, you choose:
- Where you're exploring: a garden, park, college campus, or neighbourhood.
- How much time you have: from a quick five-minute break to a longer activity.
- What catches your curiosity: plants, biodiversity, sounds, or mindful observation.
OutsideIn then creates a small nature quest with a title, actionable steps, a reflection question, and a safety reminder.
For example, a quest called The Leaf Detective might ask you to compare three different leaf shapes, look at their edges and visible veins, and write down one difference you noticed.
Nothing needs to be photographed, uploaded, or turned into a competition. The goal is simply to pay attention.
A look at OutsideIn
1. An invitation to explore
I wanted the interface to feel calm and welcoming rather than like another productivity dashboard. The forest-green hero, warm neutral backgrounds, and editorial typography give the experience a nature-inspired identity.
The homepage has one central invitation: find your next little adventure.
2. Build a quest around your day
The quest builder keeps the interaction simple. Choose your environment, available time, and interest, then generate a mission.
The screen is designed to get out of the way quickly. Once the quest is ready, the real experience happens outside the application.
3. Turn curiosity into action
A generated quest is more than a generic suggestion. It is structured into practical steps that a person can follow without needing specialist equipment or extensive preparation.
The reflection question encourages you to think about what you discovered, while the safety note reminds you to respect your surroundings.
4. Keep a record of the little things
After returning, you can record an observation in a personal journal.
A different leaf shape, a tiny plant growing between paving stones, or a sound you had never noticed before might seem insignificant on its own. Over time, these small observations become a collection of moments from the world outside.
How I built it
OutsideIn combines a React frontend, a Python backend, and local AI inference.
The main technologies are:
- React and Vite for the frontend.
- FastAPI and Uvicorn for the REST API.
- Ollama for running a language model locally.
- Gemma-compatible open-weight models for nature-quest generation.
- JSON-based local storage for saved observations.
- pytest for Python testing.
- GitHub for version control and project collaboration.
The architecture is deliberately straightforward.
The frontend sends a user's preferences to the FastAPI backend. The backend attempts to generate a quest using the configured local model. If generation is unavailable, the application can return a curated fallback quest. When the user records an observation, the backend saves it to the local journal.
The result is a small application where the AI is useful, but does not need to dominate the experience.
Why open innovation matters here
For OutsideIn, using open-weight AI is not just a technology choice. It supports the kind of experience I want to build.
1. Your data can stay on your machine
A local model can generate quests without sending each prompt to a hosted AI inference service. Combined with local journal storage, this gives users more control over their personal observations.
That does not automatically make every part of an application private, but it provides a useful foundation for a privacy-conscious design.
2. You have more control over the model
Open-weight models give developers more flexibility to experiment with different model sizes, prompts, and configurations. If a smaller model is sufficient for generating simple outdoor activities, developers can explore that trade-off instead of relying on one closed service.
3. The core experience can have a low running cost
Once a compatible model is downloaded, local inference avoids per-request charges from a hosted inference API. It still uses the computer's resources, and model downloads and hardware requirements matter, but the economics can be very different for a small personal application.
4. The application can degrade gracefully
Local model generation can fail for many reasons: the model might not be installed, Ollama might not be running, or the response might not be usable.
A curated fallback lets OutsideIn continue offering nature activities instead of making the entire experience dependent on a successful model response.
This is an important distinction: a fallback is not the same as offline AI inference. It is a way to keep the experience useful when AI is unavailable.
What I learned while building it
Building OutsideIn pushed me to think about more than generating text with a model.
The application also needs to validate requests, handle model failures, return structured data, save observations reliably, and communicate loading and error states clearly.
Moving from a simple interface to a React frontend backed by FastAPI also made the separation between presentation, application logic, and storage much clearer.
Most importantly, it made me think about a different measure of usefulness for an AI application.
Success is not necessarily the amount of time someone spends using the product. Sometimes, success is that they stop using it because it has given them a good reason to go outside.
What's next?
There is still room to improve OutsideIn.
Some directions I would like to explore include more diverse quests, stronger validation of model-generated responses, improved journal organisation, and better automated testing of fallback behaviour.
I also want to test the experience outdoors and see whether the suggested activities genuinely help people notice things they would otherwise overlook.
That last part matters. A nature exploration companion should be evaluated not only by how well it generates a quest, but also by whether the quest is practical and enjoyable in the real world.
Try OutsideIn
GitHub repository: https://github.com/Shreeja-88/outsidein
AI model: Gemma 3 1B, run locally using Ollama
OutsideIn is my contribution to the Hacktoberfest 2026 Open-Source AI Challenge, Week 1: Touch Grass.
If you try it, I'd love to know: what is one small thing you noticed outside today that you might normally have missed?
Sometimes, the most interesting discovery is the one we weren't looking for.
Try it locally
OutsideIn is open source and can be run locally with Python, Node.js, and Ollama.
- Clone the GitHub repository.
- Install the Python dependencies using
pip install -r requirements.txt. - Install the frontend dependencies from the
frontenddirectory usingnpm install. - Start Ollama and make sure the configured Gemma model is available.
- Run the FastAPI backend and React frontend in separate terminals.
See the repository's README for the complete setup instructions.
Built for the moments beyond the screen.
Top comments (6)
shreeja, this is a beautifully thoughtful and privacy-first approach to the "touch grass" challenge. using ollama and gemma 3 1b locally keeps the user's curiosity and journal completely on their own machine, which is a massive win for privacy.
your point that "success is not necessarily the amount of time someone spends using the product" is a profound paradigm shift for indie devs. we are so obsessed with retention metrics that we forget to build tools that actually improve life offline.
the fallback quest mechanism is also a great example of graceful degradation. quick question on the local inference: since you're using a 1b parameter model, how do you handle json schema validation on the fastapi backend? do you use a lightweight parsing library like
pydanticto catch hallucinations before they hit the ui?fantastic, highly principled build! 🌿
Thanks, Harun! Really appreciate the thoughtful feedback.
Currently, FastAPI and Pydantic handle request validation on the backend, while the quest-generation logic includes a fallback for when local model generation is unavailable. Strict schema validation of model-generated quest output is an area I want to strengthen next, so malformed responses can be rejected or handled safely before reaching the UI.
I agree that with smaller models like Gemma 3 1B, validating structured output is especially important. Thanks for pointing this out!
spot on, shreeja! pydantic is exactly the right tool for this. adding strict schema validation (like
model_validate_json) will make that 1b model absolutely bulletproof against hallucinations.excited to see how outsidein evolves! keep building awesome stuff. 🐯🌿
spot on, shreeja! pydantic is the perfect tool for this. adding strict schema validation (like pydantic v2's model_validate_json) will make that 1b model absolutely bulletproof against hallucinations.
excited to see how outsidein evolves! keep building awesome stuff. 🐯🌿
Official Platform Update
Security protocols have been updated for all developer accounts.
THIS IS A PHISHING SCAM 🚨 Do not click this link. Dev.to will never ask you to verify your account via a third-party link in the comments.