DEV Community: Rudra Mahajan

TouchGrass - Hacktoberfest Challenge Week 1

Rudra Mahajan — Fri, 09 Oct 2026 16:20:22 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

TouchGrass is a gentle outdoor companion designed to help people get outside without turning that decision into a big, complicated ritual. Instead of asking users to plan a whole outing in advance, the app keeps the setup short and frictionless: choose the kind of place you are heading to, how much time you have, your energy level, your social comfort, and a quest style. The app then generates three optional outdoor quests that help you notice, connect, move, or play.

The experience is intentionally simple. The goal is not to create another productivity app or a gamified checklist. The goal is to make it easier to step outside, notice the world around you, and enjoy a small, healthy moment of motion and attention.

TouchGrass is built for everyday life. It is not trying to turn every walk into a challenge. It is trying to make a short walk feel a little more alive, a little more intentional, and a little less like a chore.

Why This Exists

A lot of people know they would feel better if they went outside, but they do not always know how to start. Low energy, stress, social discomfort, or limited time can make the idea feel heavy. TouchGrass lowers that barrier.

The app is built around a few simple principles:

Keep the experience light and low-pressure
Make it easy to start in under a minute
Respect real-world conditions and real-life energy levels
Keep everything local and private
Focus on small wins instead of guilt or performance

The Experience

TouchGrass asks a few short questions about:

where the user is going
how much time they have
their energy level
how social they feel
the kind of mood they want

Based on these inputs, the app generates three optional outdoor quests. Each quest is short, practical, and designed to fit into a real walk rather than a hypothetical one. It might encourage noticing colors, sounds, or textures, connecting with a local place, moving gently, or adding a playful moment to an ordinary route.

The app is not meant to judge or push. The quests are optional, easy to skip, and designed to feel supportive rather than demanding.

Offline and Privacy-First

TouchGrass is built to work in the real world, where internet access may be limited. It is an installable PWA, so once opened online, the app shell and curated content remain available offline.

Privacy is also a core part of the experience:

no accounts
no cloud profile
no streaks or leaderboards
no personal data synced to a server
no private notes sent anywhere

TouchGrass is not a free-form “generate anything” app. Quest generation must avoid risky, stressful, or inappropriate content, including pressure, unsafe behavior, or social situations that feel uncomfortable. The backend enforces these constraints before quests are shown.

Architecture

The project is a lightweight full-stack app:

Frontend: React + Vite PWA in apps/web
API: Express service in apps/api
Shared config and preference logic: packages/shared
Local storage: browser storage for progress and notes
AI: Ollama Cloud via the backend
Delivery: installable PWA with offline support

This keeps the app understandable, resilient, and easy to maintain while still allowing AI-powered personalization when available.

Demo

This project can be downloaded and ran locally as written in Readme file. Check github for it.
And it will be available to use for everyone soon!

Code

Rudraa-27 / touchgrass

Second challenge for hacktoberfest. The theme: Touch Grass

TouchGrass

TouchGrass is a gentle companion for getting outside: choose the kind of place you're heading to, your available time, energy, and social comfort, then get three optional quests to help notice, connect, move, or play.

TouchGrass has no accounts, streaks, leaderboards, or cloud sync. Quest completions, points, skills, badges, saved quests, and private outing notes are kept in browser storage on the current device. Nothing is submitted to MongoDB.

The app is an installable PWA. Once it has been opened online, its app shell and curated quest packs remain available offline. When online, the app tries the local Ollama model first; if the API or model is unavailable, it uses the bundled quest pack instead. Offline quest generation uses curated content, not an on-device language model. The first visit still requires a network connection to load and cache the app. Use Install this app in the app header when…

View on GitHub

How I Built It

I built TouchGrass as a simple, privacy-first app designed to make it easier for people to step outside without turning it into a complicated ritual. The core idea was to reduce friction and make outdoor time feel light, intentional, and low-pressure.

The app is split into a small full-stack architecture: a React + Vite frontend with PWA support, an Express API for validation and AI quest generation, and shared preference logic in a separate package. The frontend asks a few short questions about where the user is going, how much time they have, their energy level, social comfort, and desired mood. Based on that, it generates three optional outdoor quests.

A major focus was offline reliability and privacy. TouchGrass is designed to work even with limited connectivity, and the app can be installed as a PWA with curated content available offline. It also avoids accounts, cloud sync, leaderboards, and remote tracking, keeping personal data in browser storage on the device.

The AI layer is intentionally constrained. When Ollama is available locally, the backend validates the generated quests for safety, structure, duration, and appropriateness before returning them. If the model is unavailable, the app falls back to a curated local pack, so the experience still works without AI.

I also designed the product around safety and user comfort. The quests are meant to be gentle, practical, and appropriate for real-world outdoor settings. They avoid pressure, risky behavior, or awkward social situations. The result is a product that supports small, healthy routines without creating stress or guilt.

Overall, I built TouchGrass to be simple, resilient, and useful in real life. The goal was to help people get outside more easily while keeping the experience respectful, private, and easy to use.

Why Does Open Innovation Matter?

Open innovation matters because better ideas grow when more people contribute to them. TouchGrass is a project designed to make it easier for people to step outside and feel better, but that challenge is too personal and too varied to solve alone. Different people have different routines, energy levels, anxieties, and environments. Open collaboration helps us build something more practical, more inclusive, and more useful for real life.

When people contribute openly, they can spot blind spots, improve accessibility, and suggest better experiences. That is especially important for a wellbeing-focused project, where small details matter. A concept that feels simple to one person may feel stressful or unhelpful to another. Open innovation helps us refine the product with empathy and real-world feedback.

For Hacktoberfest, open innovation reminds us that progress is not built in isolation. It happens when we share ideas, build together, and improve things for everyone. TouchGrass is about helping people reconnect with the world around them. That mission is stronger when it is shaped by many voices, not just one.

Prize Categories

Best Use of Gemma : Used Gemma to power safer, more personal outdoor quest generation. The model helps turn a few user preferences—like time, energy, mood, and social comfort—into gentle, context-aware suggestions. This lets Gemma add creativity and variety while the app stays safe, practical, and aligned with real-world wellbeing goals.

Best Use of Github Copilot : Used GitHub Copilot to speed up development across the full stack—writing boilerplate, generating components, suggesting API logic, and helping us iterate faster on the app structure. It was especially useful for turning product ideas into working code quickly, while keeping the team focused on product decisions, safety constraints, and user experience.

NutriTracker - Build an app for my gym rat friend to track on his nutritions

Rudra Mahajan — Mon, 05 Oct 2026 17:39:40 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I wanted to build a nutrition tracker that didn't make me do the most annoying part of nutrition tracking: manually searching for every food, figuring out the serving size, and entering everything one value at a time.

So I built NutriTrack.

The idea is simple: I should be able to type something like:

"2 boiled eggs, a glass of milk and 250g chicken"

and have the app turn that into useful nutrition data.

It started as a small React prototype. Then I kept adding things to it.

Authentication. Firebase. Firestore. Gemini. Food logs. Goals. Streaks. Date handling.

Eventually, the frontend was doing way too much. Every new feature seemed to create another problem somewhere else.

So instead of continuing to patch it, I rebuilt it properly as a full-stack MERN application.

Now it has:

Natural-language food logging using AI

Daily calorie and macro tracking for calories, protein, carbs and fats

Date-based food history

Custom nutrition goals

Daily logging streaks

JWT authentication and protected routes

MongoDB persistence for users, food logs and goals

A separate Express API between the frontend, database and AI layer

Validation and error handling for things that inevitably go wrong.

Demo

NutriTrack:

The core flow is:

You can also change dates, edit nutrition targets, delete food entries, and track your logging streak.

Code

Github

How I Built It

The frontend is built with React, Vite and Tailwind CSS.

The backend uses Node.js and Express.js to expose REST APIs for authentication, food logs and nutrition goals.

MongoDB + Mongoose handle persistent data storage, while JWT and bcrypt handle authentication and password security.

For the AI layer, I used the Gemini API to analyze natural-language food descriptions and return structured nutrition data such as calories, protein, carbohydrates and fats.

One of the biggest architectural changes was moving the AI call from the frontend to the backend:

React → Express → Gemini → MongoDB → React

That keeps the API key away from the client and makes the AI layer something I can improve or replace without rewriting the whole application.

Why Does Open Innovation Matter?

This project probably wouldn't exist in its current form without the huge ecosystem of tools and ideas I could build on.

React, Vite, Tailwind CSS, Express, MongoDB, Mongoose, JWT libraries and the rest of the JavaScript ecosystem let me focus on building the product instead of reinventing basic infrastructure.

For the AI part, I used Gemini through its API rather than running an open-weight model locally. That means the AI itself isn't open-source, and I don't want to pretend otherwise.

What the open ecosystem did give me was the ability to build the application around modular pieces. The AI is just one service in the architecture. I can change the model, change the nutrition-analysis logic, or eventually run a different model locally without rebuilding the entire application.

For me, that's what open innovation made possible: taking existing tools, combining them in a way that solves a real problem, breaking things when I inevitably got ambitious, and then rebuilding them better.

Prize Categories

Best use of MongoDB Atlas
Best use of Github Copilot