Local AI for Outdoor Activities: TouchGrass AI
See how TouchGrass AI uses local AI to turn your interests and free time into outdoor missions. Explore its design, privacy trade-offs, and lessons. Try it.
TouchGrass AI: Using Local AI to Help People Step Outside
Most AI products ask for more of your attention: another prompt, another feed, another reason to stay on a screen. I wanted to try a different angle. What if an AI app could help someone choose something to do after they put their phone down?
That question led me to build TouchGrass AI, a local-first app that turns a person's interests, available time, and energy level into a practical outdoor mission. Instead of dumping an open-ended response and making the user figure out what to do, it suggests a short list of activities - walking, gardening, birdwatching, outdoor photography, or mindfulness.
I built it for Week 1 of the Hacktoberfest Open-Source AI Challenge, themed "Touch Grass." The point isn't that it uses an especially large model or a fancy pipeline. The interesting part is the product decision: using AI to make the switch from screen time to an offline activity feel easier.
This article walks through how the app works, why I chose local inference, what happens when a model response fails, and where this approach has real limits. It's not meant to claim local AI magically fixes every privacy or connectivity problem. It's about what a small, focused AI feature can do - and what you still have to think through when you build one.
Why build an AI app that encourages less screen time?
Most consumer technology is built to keep you using it. That's not always a bad thing - maps apps help you navigate, collaboration tools help teams work. But it's also easy for the success metric to quietly drift from "did this help?" to "how long did someone keep using it?"
TouchGrass AI starts from a different question: can the app help someone take a useful next step away from the device? The goal is to reduce the effort it takes to pick an outdoor activity. You might want to get outside, but you only have a little time, you're running low on energy, or you just don't know what to do. "Go for a walk" doesn't really handle any of that. A short, specific mission can.
From interests to a doable next step
People choose their preferences and tell the app things like how much time they have and their energy level. Then the app turns that into an activity with practical instructions. The activity types are:
- Walking and exploring nearby places
- Gardening and spending time with plants
- Birdwatching and observing wildlife
- Outdoor photography
- Mindfulness and relaxing outside
This isn't trying to replace a planning tool or act like a full-on recommendation engine. It's narrower on purpose: take a few lightweight inputs and return an idea that someone can actually act on. And honestly, the narrower the scope, the less extra work (and sensitivity) you need from the user.
The first version doesn't claim it can find the best route, assess local conditions, or replace expert advice. It generates a mission based on what people input. That boundary matters for an early product - get one part of the experience working before you add features that require more data, more safety thinking, and more reliability work.
The product question behind the model choice
It would have been easy to treat this as a model demo: send a prompt to an AI service, show the answer, and call it a product. But the model is only one piece of the experience. The interface has to clearly show what the user can provide, the output has to be usable, and a model failure can't leave someone staring at a broken page.
So the project combines preference selection, mission generation, and fallback handling. The AI adds personalization and variety, but the core job stays simple: help someone pick an outdoor activity that fits into their day.
There's also a short demonstration video that shows the interface, activity selection, mission generation, and the local AI workflow. The open-source repository is available under the MIT License if you want to inspect or adapt the implementation.
How TouchGrass AI turns preferences into missions
TouchGrass AI is built on a pretty standard web stack with a local language model:
- Frontend: React, TypeScript, and Vite
- Backend: Python and FastAPI
- Local AI runtime: Ollama
- Model: Qwen2.5 1.5B
- Web experience: Progressive Web App (PWA)
- Backend tests: Pytest
The separation is intentional. The frontend collects preferences and handles the user experience. The FastAPI backend prepares the request and coordinates with the local inference runtime. Ollama runs the selected model on the user's machine, so mission generation doesn't require sending every request to a hosted AI inference API.
The request path
A mission request goes through four steps at a high level:
- The user selects interests and provides available time and energy level.
- The frontend sends those preferences to the backend.
- The backend asks the local model to generate a relevant outdoor mission.
- The response gets checked before it's returned to the interface.
The prompt isn't the whole system. A language model can return malformed, irrelevant, or just plain unusable output. If you treat generated text as automatically valid, the feature becomes fragile. So the backend validates the response and can return a predefined mission when the output is invalid or the AI request fails.
That fallback matters because people are here for an activity suggestion, not to debug a model connection. In a real product, the fallback strategy should match the risk. For a low-risk idea, a curated fallback list might be fine. For higher-stakes recommendations, a generic default can be the wrong move.
Testing failure paths, not just the happy path
The backend tests cover health checks, request validation, successful local AI responses, invalid model output, and connection failures. The project reports that all six backend tests passed and that the frontend production build completed successfully.
That's a good starting point, but it's not the same thing as proving the app works on every device in every situation. Tests confirm defined behavior under known conditions. You still need to try it in the real setups people will use.
I also verified mission generation with the internet disconnected, after downloading the model. One important detail: "local inference" doesn't automatically mean "works offline from a completely blank device." The model has to be downloaded first, and the web app has to already be loaded or installed. Once those prerequisites are in place, the local mission-generation flow can run without a continuous internet connection.
Users should see that clearly. "Works offline" can imply zero setup, even though the experience depends on what's already cached or installed. Setting expectations is part of reliability, not just documentation.
What local inference changes - and what it does not
With Ollama and Qwen2.5 1.5B, the model runtime runs locally on the user's machine. For TouchGrass AI, that means mission-generation requests don't need to be sent to a hosted AI inference provider. It also gives the project more control over the inference path and enables offline generation after the model and app are available locally.
But the wording matters. Local inference is not a blanket privacy guarantee for the whole application. A product can run its model locally and still use remote services for things like analytics, maps, or other features. Privacy depends on the full data flow - what the frontend and backend send to other systems. For TouchGrass AI, the specific claim is simple: mission generation uses a local model instead of relying on a hosted inference API.
Benefits for this use case
There are a few practical reasons to use local inference here:
- More control over the inference path: You can inspect the backend, change prompts, adjust fallback behavior, and try different models.
- Less dependence on a hosted AI provider: You're not hitting a remote inference service for every mission request.
- Offline capability after setup: Mission generation can keep running without a continuous internet connection once the app and model are already on the device.
- Room to experiment: Because it's open source, people can modify local runtimes and models as they evolve.
These benefits fit a small app where the generated output is short and doesn't require live info from the web. If the app later adds things like live weather or location, that introduces new data and connectivity decisions. Local inference won't remove those external dependencies by itself.
The costs are real
Running locally shifts some infrastructure requirements onto the user. The model takes disk space, inference uses local compute, and performance depends on the device. Speed and output quality can vary. A small model can be easier to run, but it won't always match the quality or consistency you'd get from a larger hosted model.
There's also a distribution and onboarding cost. People need to download the model and understand what "offline workflow" actually means before they can use it. For a technical audience, that may be fine. For a broad consumer audience, downloads and runtime setup can be a real barrier.
So the trade-off is straightforward: local inference gives you more control and reduces reliance on remote inference, but it adds setup and hardware constraints. Whether that's worth it depends on the product, the user, and whether local inference meaningfully improves the experience. "Local" is an architectural choice, not a substitute for evaluating the full user experience.
What I learned and what I would build next
Building TouchGrass AI involved more than wiring a React interface to a language model. It meant designing a small preference-based flow, integrating local inference, checking generated responses, handling connection failures, and testing what happens when the model doesn't cooperate.
The main engineering lesson is simple: keep the model inside a system with predictable behavior. The model can generate the variation, but validation and fallbacks protect the product from treating every response as trustworthy or usable. For an early prototype, that boundary can be straightforward. It still needs to exist.
The project also clarified the offline story. Testing without internet is only useful if you account for what has to happen before the test: downloading the model and loading or installing the application. A system can be offline-capable without being setup-free. Making that distinction explicit prevents "offline" from sounding like a magic button.
A focused roadmap
There are plenty of next steps, but each one creates new product and engineering questions:
- Weather-aware missions: Weather could make suggestions more relevant, but it's an external dependency and can change whether an activity makes sense.
- Location-based ideas: Nearby recommendations could be helpful, but location is sensitive. It should be optional, with a clear explanation of what's collected and where it's processed.
- Mission history and progress: A history could help people revisit activities. It also creates data retention and UI decisions. Tracking should support the user instead of turning into another engagement loop by default.
- More models and configurable inference: More model options could improve flexibility, but too many settings can make the app harder to use. Configuration should solve a real need.
- Accessibility and offline improvements: Better accessibility and clearer offline behavior would improve the core experience without changing the app's purpose.
- User feedback: Feedback could help measure mission quality, but it should be collected in a way that's proportionate and clear.
Order matters. I'd focus first on reliability and accessibility in the existing mission flow, then add features that depend on location, weather, or stored history. Those additions can be valuable, but they also expand the amount of data and the number of failure modes the app needs to handle.
The bigger idea is worth carrying forward: AI doesn't always have to keep people engaged with technology. Sometimes it can help with a decision, then get out of the way. That's a product outcome worth measuring alongside model quality - did the suggestion help someone do the thing they came to do?
Conclusion: make the AI useful, then let the user leave
TouchGrass AI is a small experiment, but it's testing a useful product principle: AI can support an offline action instead of competing for more screen time. The implementation combines a simple preference flow with local inference, response validation, and fallback missions. It also makes the trade-offs concrete: you get a locally run model workflow, but you need storage, suitable hardware, and a bit of setup.
If you're building an AI feature, start with the user outcome and the failure path - not the model demo. Then decide whether local inference really improves the experience enough to justify the costs. You can explore the code, watch the demo, and share ideas for making the project even more useful. Less scrolling isn't the point. Helping someone get outside is.