TouchGrass AI: I built an outdoor quest app with Ollama and local-first storage

Shashank Chakraborty — Tue, 06 Oct 2026 21:32:15 +0000

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.

TouchGrass: when quests vanished into tranquility

You

okay committed and pushed — lets go to the next phase build

Agent

We moved on to the next phase: keep the quest creation loop useful from first prompt to a saved outing.

You

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 ??

Agent

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.

You

i noticed the icon in this pg is different keep the leaf one i love it

Agent

The leaf stays. The brand mark was made consistent across the app.

You

okay whats next and make it

Agent

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.

You

okay i guess all done so can we move towards deployment?

Agent

We prepared Vercel deployment with server-side Ollama credentials, structured quest validation, and a ready-made fallback if generation fails.

You

for this one i used ollama's api key and then used a model used in ollama for gemma i believe

Agent

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.

You

worked perfectly in my phone too. the photo clciking is perfect

Agent

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.

DEV Community: Shashank Chakraborty

TouchGrass AI: I built an outdoor quest app with Ollama and local-first storage

TouchGrass AI: turning an AI prompt into a reason to put my phone away

What I built

How it works

Why open models matter here

What I learned

Build session

Try it

Further reading