Dev
My dog won't let me stay inside
Dev.toUnited States · NORTH AMERICA
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass Usually when I look at a challenge, I don't react much. Most of them have exactly the vibe I expected. This one...
This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Usually when I look at a challenge, I don't react much. Most of them have exactly the vibe I expected. This one was different. I kept giggling the whole time I read it. They actually want us, the devs, to build something that gets people to touch grass.
It reminded me of every uni holiday, when my friends would say:
CompSci finally touches grass
What I Built
There are thousands of reasons to get out the door. The problem is, people just don't want to.
We make excuses, or our body simply decides it's done for the day. Doomscrolling and bedrotting start to sound like better choices.
A hike or a day of planting trees sounds fun in theory, but I can come up with a hundred excuses to put it off:
Going alone feels kind of sad
I'd need to buy gear first
We can just do it tomorrow
I'm working this weekend, I'll sort it out later
Boooooo!
People don't go outside because they don't feel like it, and nobody is there to drag them out. So instead of trying to motivate people all the time, why not go with an easier solution?
Give them someone who will force them to go outside.
And I mean it. They'll have to go outside, because they need to walk their dog.
Let me introduce you to GRASS DAWG.
Grass Dawg is a mobile app where you raise your own virtual pet. (I love dogs, so it's a dog.) Once you adopt your pup, you're responsible for its happiness.
Skip going outside for too many days and your dog gets miserable. Eventually, it runs away. Every day it's gone adds more distance to the search, and you have to walk all of it to bring your dog home.
When it comes to dogs, we don't play.
If dog walking sounds boring, don't worry. Grass Dawg keeps every walk interesting, whether you want to explore your city or just get your body moving:
- Complete side quests to feed your dog
- Visit a lookout because your dog has never seen one
- Snap a photo after each activity
At the end of the walk, you get a recap of your day, just like the stories you'd post anyway, so you can see how good your day actually was.
About screen time
I'll be honest: Grass Dawg can't get your screen time to zero. The whole app is built around you and your dog, and that relationship lives on your phone.
What it does is keep the screen part short. During a side quest, your dog sulks with its back turned and won't come out until the quest is done. And let's be real: given the choice between staring at a dog that refuses to look at me, or looking at the street and the view, I'm putting my phone away until I find something worth photographing.
I took Grass Dawg out for a proper test run, and the screen time numbers told the whole story.
At 9am, I had barely rolled out of bed and my phone already showed 50 minutes of screen time. Half of that was TikTok (I didn't mean that I swear...). Honestly, seeing it laid out like that was a bit depressing.
Then I headed out with Pickle. By 1pm, my total was only 1 hour and 3 minutes. That means across four hours outside, I spent just 13 minutes on my screen, and most of those were the 10 quick unlocks to check my next quest.
Who it's for
Everyone!
People who know they should get out more. People who have a free day and no idea what to do with it. Or anyone who just wants a pet and a little sense of progress in their life.
And here's my favourite part of building it: The app actually kept me outside, because I had to test whether it worked.
Honestly, if it can get a developer in the middle of a build to touch grass, it can get anyone.
So, what do you think?
Demo
This app is designed to be a mobile app so open the URL with your phone to have the best experience.
Code
Have a look at my code in here.
Fetch Quest
A virtual pet dog that refuses to come out until you go outside. All AI runs on your phone using open-weight models, so it works offline after the first load and your photos never leave the device.
Entry for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.
What works so far (step 1 and 2)
- Home screen with the pet sulking, facing the wall
- Camera snapshot checked by CLIP (Transformers.js) to decide indoor vs outdoor
- Pet wakes up and celebrates when you're outside
- System check panel: WebGPU support, on-device language model download (Gemma 3 1B by default, with Qwen2.5 alternatives), and a test line from the pet
- Pet stats saved between sessions
Run it
npm install
npm run dev
The dev server prints a Network URL like https://192.168.x.x:5173. Open that on your phone (same Wi-Fi). It uses a self-signed certificate, so accept the browser warning…
How I built it
The idea was simple: make a walk around the neighbourhood feel like a little adventure, with a dog that actually cares whether you go outside.
The brain behind Pickle is Gemma 3 1B, an open-weight model that runs entirely in the browser through WebLLM. The first launch downloads the model, and after that everything happens on your phone. When Pickle comes up with a quest for you, it’s generated right there on your device, with no cloud AI call involved. I loved that part, because it means your walks and photos stay with you.
Quests only matter if they happen in the real world, so the rest of the app is about getting you out the door. When you snap a photo for a quest, CLIP ViT-B/32 running through Transformers.js checks whether you actually found what Pickle asked for. No sneaky photos of your bedroom wall. To give Pickle somewhere worth sending you, OpenStreetMap and SerpApi pull in interesting spots nearby, like parks, cafés and lookouts you might never have noticed.
The whole thing is built with React and Vite and ties together on-device AI, your camera and a map of your city. Underneath all the tech, it’s really just one very good boy giving you a reason to get some fresh air.
Why Does Open Innovation Matter?
Grass Dawg only works the way it does because the AI runs on the phone itself. The dog's eyes are CLIP ViT-B/32 running through Transformers.js, and its voice and quest ideas come from Gemma 3 1B running through WebLLM. Both download once, then run entirely in the browser. That one decision shaped everything else about the app.
It keeps working where people actually walk. Parks, bush tracks, tunnels and the far end of a beach are exactly where signal drops out. With a closed API, every photo check and every dog reaction would be a network request, and the dog would freeze the moment the walk got interesting. Because the models live on the device, tap-to-look, quest photo matching and the dog's lines all keep working with no connection.
Your walks stay yours. A walking app that uses the camera builds a detailed picture of someone's life: where they live, when they leave the house, which routes they take, and photos of the streets around them. Sending that to a third-party server for every check was something I didn't want to ask anyone to accept. In Grass Dawg, quest photos are matched on the device, the route and recap are stored locally, and nothing is shared unless the user chooses to share their walk recap.
It costs nothing per walk. A single active walk can involve dozens of model calls: checking whether you're outside, reacting to what you show the dog, verifying quest photos and writing quest suggestions. With a paid API, the more someone walks, the more the app costs to run, which is the opposite of what an app about getting outside should reward. Running locally, the hundredth walk costs the same as the first: nothing.
I could control and change the model. Owning the model meant I could constrain it tightly. Quests are limited to categories CLIP can actually verify, so the language model can't invent a mission the app can't check. It also meant I could swap models freely during development. I started with Qwen2.5 and moved to Gemma 3 1B when it suited the quest writing better, without changing providers, keys or pricing plans.
The trade-offs, honestly. Running on-device means a large first download, so the app shows a one-time setup screen and works best on Wi-Fi the first time. Phone browser support for WebGPU also varies. And not everything is local: finding Explore destinations uses OpenStreetMap and SerpApi, which need a connection, so the app pre-downloads destination data for the user's city while they're online. The core loop of going outside, showing the dog the world and completing quests runs entirely on open models on the phone.
On my own test walk, [4 hours outside, 12 minutes of screen time]. That's the point of the whole build: the open models do their work quietly in the pocket, so the walk can be the main event.
My Agent Session
I found out about DevRelay too late to record my agent session properly. Instead, I worked with my agent to put together a structured summary of the whole development process: every phase, from understanding the challenge and shaping the idea to the final build, along with the key decisions made along the way.
It isn't a verbatim transcript of my prompts and messages, but it should give you a clear picture of how Grass Dawg came together.
{
"title": "Grass Dawg development session",
"format": "session-summary",
"coverage": "From the first request to explain the Touch Grass challenge, through ideation, design, the first code and the fixed dog interactions, then from the later Tap-to-look and outdoor camera work through the project discussion immediately before the first request to push the project to GitHub.",
"transcript_note": "This is a structured summary, not a verbatim transcript. It combines two parts of development: the early ideation and setup conversation, and the later build session. The full turn-by-turn transcript was not available for export, so missing replies have not been reconstructed.",
"project": "Grass Dawg, a mobile-first dog companion app that encourages outdoor walks with quests.",
"timeline": [
{
"phase": "Understanding the challenge",
"items": [
"Reviewed the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass, including the requirement that open-source AI must be what makes the project work.",
"Identified the key judging hint: the screen should be the shortest part of the experience, with bonus points for testing the build outside.",
"Clarified the difference between open AI (open-weight models and open-source frameworks that can be downloaded and run locally) and closed AI (models only reachable through a provider's API).",
"Listed the open advantages to highlight in the post: offline use, on-device privacy, zero cost per use, and the freedom to swap, constrain or fine-tune models."
]
},
{
"phase": "Choosing the idea",
"items": [
"Started from the user's idea of a virtual pet that must be walked outside.",
"Identified the main weakness: a step-counter pet does not need AI, so the open model had to become essential to the experience.",
"Compared alternatives (a Side Quest app and an offline coastal explorer) and ruled out edible plant identification for safety reasons.",
"The user proposed combining the pet with side quests: the pet gets people outside, and quests reduce screen time.",
"Replaced the planned coin shop with rewards tied to what was found, since browsing a shop would add screen time."
]
},
{
"phase": "Refining the concept",
"items": [
"Defined the core mechanic: the pet sulks facing the wall until the user goes outside, then comes alive.",
"The pet sets a side quest and hides until it is completed, turning reduced screen time into part of the game rather than a rule.",
"Target users: people exploring their city on a free day.",
"Replaced continuous real-time camera analysis with tap-to-look snapshots to save battery and keep screen time short.",
"Planned outdoor detection with a CLIP indoor/outdoor check, with GPS distance from home as an optional second signal.",
"Added a growing pet diary with daily entries written by the local language model, plus pet stats."
]
},
{
"phase": "Design document",
"items": [
"Wrote a design document covering the overview, core loop diagram, game mechanics, interaction table, architecture diagram, why open innovation matters, scope and risks, a 7-day build plan, a field test plan, a coding agent starter prompt and a submission checklist.",
"Planned the field test headline metric: total time outside compared with total screen-on time."
]
},
{
"phase": "UI direction and naming",
"items": [
"Wrote a Stitch AI prompt for six screens: breed selection, indoor sulking home, AR camera view, hidden side quest screen, quest complete and diary.",
"Kept the art style original rather than copying an existing game's characters.",
"Noted that Stitch produces static screens, so smooth dog movement must come from the implementation.",
"Explored app names, using Fetch Quest as the working name during early development."
]
},
{
"phase": "Tech stack and models",
"items": [
"Chose a browser-based PWA (React and Vite) so judges can open a link and all AI runs on the phone after a one-time download.",
"Selected CLIP ViT-B/32 through Transformers.js for zero-shot image matching, and a small open-weight language model through WebLLM (initially Qwen2.5 1.5B with a 0.5B fallback) for quests, reactions and diary entries.",
"Discussed the user's request to use MongoDB: recommended a local-first design (RxDB on top of IndexedDB) with optional MongoDB Atlas sync, so photos and locations never leave the device.",
"Flagged the roughly 1 GB first download and WebGPU support on phones as the main risks."
]
},
{
"phase": "Dog movement and 3D assets",
"items": [
"Explained that smooth dog movement comes from animation clips built into a rigged 3D model, played and cross-faded in three.js through React Three Fiber.",
"Compared sources: the free CC0 Quaternius Animal Pack Vol.2 dog, the Quaternius Farm Animal Pack, a paid 15-breed animated dog pack, and Sketchfab models with varying licenses.",
"Chose the free Quaternius dog for its CC0 license and small file size, with breed choice handled by recolouring one rigged model.",
"Noted that Mixamo only animates humanoid characters and that retargeting four-legged animations by hand is too slow for a one-week build."
]
},
{
"phase": "First code: outdoor wake-up",
"items": [
"Built the first version: a sulking home screen with an animated placeholder SVG dog, stat bars, and a camera snapshot checked by CLIP for indoor versus outdoor.",
"Added a System check panel to confirm WebGPU support, download the language model and time a test reply on the phone.",
"Ran WebLLM in a web worker so animations stay smooth, and served the dev server over HTTPS on the local network so phones allow camera access.",
"Walked through running the project locally and accepting the self-signed certificate warning."
]
},
{
"phase": "Fixed dog interactions",
"items": [
"Defined a fixed interaction table: water bowl, fountain or pond, grass, bench, tree, dog, bird, flowers, street art, cafe, statue and bridge, each with an action, stat effect and fallback lines.",
"Added background labels (roads, cars, footpaths, walls, sky) so CLIP does not force ordinary scenery into an object.",
"Added a confidence threshold, half rewards for repeated objects, and a limit of three looks per round so the camera does not become the main activity.",
"Added interactions for a person, chair, table and jumpable shapes (low walls, steps, rocks, logs, crates), supporting several wordings per object.",
"Mapped each action to an animation clip name, to be updated once the real 3D dog clips were known."
]
},
{
"phase": "Platform decision",
"items": [
"Discussed building a native mobile app: native would allow real AR ground tracking, better notifications and faster on-device inference.",
"Decided to stay with the PWA for the submission, because judges can open a link instantly and a native rewrite would not fit the deadline.",
"Noted Capacitor as a way to wrap the web app later, and a native React Native version with real AR as a post-challenge next step."
]
},
{
"phase": "Outdoor camera and dog behavior",
"items": [
"Implemented Tap-to-look and indoor/outdoor mode behavior.",
"For outdoor mode, keep the dog in the live camera view and let it perform actions for a short interval.",
"Added dog movement concepts such as running, drinking, sitting, and sunbathing."
]
},
{
"phase": "Walk modes and quests",
"items": [
"Added relaxed and active walk concepts, with side quests available during active walks and occasional suggestions during relaxed walks.",
"Created daily item/activity quests and city-bounded Explore quests.",
"Explore destinations should favor specific, relaxing outdoor places and hikes, with commercial venues minimized.",
"Quest recommendations should refresh and completed quests should be recorded in history."
]
},
{
"phase": "Camera, proof, and walk recap",
"items": [
"Quest completion uses a camera photo rather than an uploaded image, with photo matching for validation.",
"Walk recap tracks elapsed time and route shape, includes photos, and supports sharing/downloading.",
"Active walk recaps include quest photos and quest totals; the final cover photo is separate from the quest-photo collage.",
"Route tracking should represent meaningful position changes rather than stationary phone movement."
]
},
{
"phase": "Dog profile and wellbeing",
"items": [
"Added a dog profile with editable name, happiness, weight, and an outside/home calendar.",
"Initial weight is 2 kg; the user proposed daily weight changes based on happiness and missed outdoor days, including a find-the-dog mechanic if weight reaches the minimum.",
"Completed quests automatically mark the day as an outside day.",
"Removed energy after discussing what happens when it reaches zero; retained happiness."
]
},
{
"phase": "Offline AI and app behavior",
"items": [
"Discussed running open-weight AI locally in the browser after an initial model download.",
"Gemma 3 1B is used through WebLLM for local quest assistance; CLIP through Transformers.js is used for image matching.",
"Discussed offline capability and pre-downloading city destination data, while noting that some integrations need network access."
]
},
{
"phase": "Camera and development settings",
"items": [
"Added camera switching and zoom controls, including pinch zoom capped at 5x.",
"Worked through camera access and startup responsiveness issues.",
"Adjusted indoor/outdoor detection and relaxed-walk quest reminder timing during development."
]
},
{
"phase": "Hosting discussion",
"items": [
"Discussed deploying the web app on Render and how to open it on a phone.",
"Troubleshot local network connection and certificate issues.",
"Discussed that deployment does not automatically preserve browser-local data."
]
}
],
"technologiesMentioned": [
"React",
"Vite",
"Tailwind CSS",
"WebLLM",
"Qwen2.5 1.5B / 0.5B",
"Gemma 3 1B",
"Transformers.js",
"CLIP ViT-B/32",
"three.js / React Three Fiber",
"Quaternius Animal Pack Vol.2 (CC0)",
"RxDB",
"MongoDB Atlas",
"Web Speech API",
"Stitch AI",
"OpenStreetMap",
"SerpApi",
"Render"
]
}
Prize Categories
- Gemma - Uses the open-weight Gemma 3 1B model with WebLLM for on-device quest generation.
- Render - Deployed on Render, with a static web app and a places API service.
- SerpApi - Uses Google Local results to help rank named places for Explore quests.