This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
TouchGrass AI: turning an AI prompt into a reason to put my phone away
I built TouchGrass AI, a small outdoor quest companion. You choose how much time you have, what kind of outing sounds good, and how much effort you want. It makes a short quest, then the app gets out of the way so you can go do it.
The latest test was on my phone: I generated a quest, took a photo for one of its tasks, and the photo stayed available with the saved quest.
Project: TouchGrass AI on GitHub
What I built
A quest is a handful of simple prompts for a walk, exploring a familiar area, noticing nature, or taking a photo walk. Tasks can ask for photo evidence. If they do, the task stays incomplete until a photo is saved.
The app keeps quests, progress, and photo evidence in the browser on that device. Photos are stored as blobs in IndexedDB, can be previewed or removed, and never go into the service worker cache. The app shell can load offline after it has been visited, and a saved quest can go with you when the signal does not.
How it works
The UI sends the selected activity, duration, and difficulty to a same-origin server route. That route asks Ollama for structured JSON, then validates the response against the quest rules before showing it. If generation is unavailable or the response is not usable, the route returns a ready-made quest instead.
For local development I run Ollama on my computer. For the hosted demo I configured Ollama's API with a Gemma model. The API key stays in the server environment; it is not included in browser code.
The browser stores the quest and its photos locally. In hosted mode, quest-generation settings and the prompt go to Ollama to produce the quest. The app does not ask for or send a location, and the photo evidence is not uploaded.
Why open models matter here
I wanted the AI to help create a personal plan, not become the activity itself. Open models let me keep local inference as a real option, change the model, and inspect the boundary between generation and the rest of the app. The hosted API makes the demo accessible without requiring each visitor to install a model, while the offline part of the experience stays useful after a quest is saved.
That trade-off is deliberate: generation needs a connection in the hosted setup, but the walk, saved tasks, progress, and photo evidence do not depend on a live AI request. A model can suggest the next small thing to notice; it should not need a permanent place in the user's pocket once the walk starts.
What I learned
The most important boundary was deciding what belongs on the server and what belongs on the phone. The server needs only the choices required to generate a quest. The browser owns the saved quest and evidence. Keeping those responsibilities separate made offline use and photo privacy easier to reason about.
I also learned that “works on my laptop” is not the finish line for a camera feature. Testing the deployed app on a phone made the whole loop real: take or choose a photo, save it, see it attached to the task, and continue the quest.
Build session
A lightly edited transcript of the build: practical decisions, one missing persistence bug, and the moment the quests briefly achieved enlightenment by vanishing into tranquility.
okay committed and pushed — lets go to the next phase build
We moved on to the next phase: keep the quest creation loop useful from first prompt to a saved outing.
okay generation too and the fallback both working fine but what happens next when i click go back home the quests vanish into tranquility. vanished. not really being saved though ??
A peaceful disappearance is charming in poetry and less charming in a quest app. We fixed the home flow so quests are saved locally and show up on the quest shelf after navigation.
i noticed the icon in this pg is different keep the leaf one i love it
The leaf stays. The brand mark was made consistent across the app.
okay whats next and make it
We continued with the next phase, adding photo evidence to tasks that ask for it. Photos are saved on-device in IndexedDB, can be reviewed or removed, and are not cached or uploaded.
okay i guess all done so can we move towards deployment?
We prepared Vercel deployment with server-side Ollama credentials, structured quest validation, and a ready-made fallback if generation fails.
for this one i used ollama's api key and then used a model used in ollama for gemma i believe
We updated the hosted setup to call Ollama's API from the server, so the key stays out of browser code. Gemma can be configured as the hosted model.
worked perfectly in my phone too. the photo clciking is perfect
The mobile test confirmed the camera/photo-picker flow works, and the evidence remains attached to the saved quest on that device. The phone has now passed its field test; the app may politely ask it to go outside.
Try it
- Source: github.com/Shashank0701-byte/TouchGrass
- The hosted demo is deployed on Vercel. (https://touch-grass-gilt.vercel.app/)
If you'd like to run it locally, clone the repository, install Ollama and the configured model, then follow the README setup steps.
Further reading
- No Internet? Your Web App Should Still Work helped frame the app-shell versus locally saved data distinction.
- Image processing that never leaves your device is a useful discussion of making on-device data boundaries observable.
Top comments (0)