DEV Community: AKSHAT JAIN

TouchGrass 🌿 — Turning Open-Weight AI into Real-World Adventures

AKSHAT JAIN — Sun, 11 Oct 2026 17:48:38 +0000

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

What I Built

TouchGrass is an AI-powered outdoor activity generator designed to help people spend less time staring at screens and more time exploring the world around them. 🌿

We often want to take a break but end up scrolling through our phones because we don't know what to do. TouchGrass aims to make that decision easier.

Users can choose their mood, available time, energy level, and whether they want to go solo or with others. The app then generates an outdoor adventure tailored to those preferences.

The goal isn't to keep people engaged with another app. It's to help them find a reason to put their phones away and step outside.

I built TouchGrass as a practical experiment in using AI to encourage real-world experiences rather than more screen time.

Demo

🌿 Try the live app: https://touchgrass-gdkp.onrender.com/

The application is deployed on Render and uses Groq for AI inference.

Code

akshat-jjain / touchgrass

An open-AI adventure generator that gives you a mission and gets out of your way.

TouchGrass

An AI that wants you to stop using it.

TouchGrass creates short outdoor micro-adventures so the screen is the shortest part of going outside. It is being built for the DEV Hacktoberfest 2026 Week 1 “Touch Grass” challenge.

Local development

Requirements: Node.js 22.12 or later and npm 10 or later.

npm ci
cp .env.example .env
npm run dev

The web app runs at http://localhost:5173; the API runs at http://localhost:3000. Vite proxies /api requests to Fastify. The API health endpoint is GET /health.

Adventure generation

The API supports two server-side providers:

AI_PROVIDER=stub uses the curated deterministic generator. It is the default for local development and tests.
AI_PROVIDER=groq uses Groq’s OpenAI-compatible chat completions API and openai/gpt-oss-20b by default. Set GROQ_API_KEY on the server. The key must never use a VITE_ prefix or be placed in browser code.

The Groq generator requests strict JSON Schema output. All provider results…

View on GitHub

The project is open source under the MIT license. Feel free to explore the code, share feedback, or contribute improvements!

How I Built It

I built TouchGrass using a TypeScript-based full-stack architecture:

Frontend: React, Vite, and TypeScript

Backend: Fastify and TypeScript

Validation: Zod for shared contracts and structured data validation

AI model: openai/gpt-oss-20b, an open-weight model accessed through Groq

Deployment: Render

The AI is central to the experience. It generates personalized outdoor activity suggestions based on the user's preferences instead of relying exclusively on a predefined list of activities.

The backend validates the generated output and applies safety checks before returning suggestions. I also implemented a deterministic fallback so the application can remain useful when AI generation fails.

API credentials stay on the server rather than being exposed to the frontend.

One of the important design decisions was treating AI output as untrusted data: a generated suggestion must pass validation and safety checks before it reaches the user.

Why Does Open Innovation Matter?

Open innovation matters because developers should have the freedom to understand, experiment with, and adapt the technology powering their applications.

By using an open-weight model, TouchGrass isn't tied exclusively to a closed-model API. The project can explore alternative inference providers, experiment with different models, and evolve its generation pipeline as requirements change.

For this project, open-weight AI made it possible to build a personalized generation experience while keeping the model integration behind a replaceable backend interface.

I'm currently using hosted inference through Groq, so the application still depends on an online service. Local or offline inference is a possible future direction, not a feature I've implemented yet.

For me, the bigger idea is that open AI technology should help developers build useful products—not just demonstrate what a model can say.

Prize Categories

I'm submitting TouchGrass for the Week 1 challenge. I'm claiming render partner prize categories at this stage.

Thanks for organizing this challenge and encouraging developers to build with open-source AI.

🌱 Less scrolling. More exploring. TouchGrass.

I Built ApnaSahayak So My Parents Don't Have to Call Me Every Time a Message Looks Scary

AKSHAT JAIN — Mon, 05 Oct 2026 06:56:04 +0000

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

What I Built

I built ApnaSahayak, a private digital helper for my parents.
My parents receive messages from banks, payment services, delivery companies, and other services regularly. The problem isn't always understanding the English. The problem is knowing:

What does this message actually mean?
Do I need to do something?
Is this safe?
Should I click this link?
Should I enter the OTP it is asking for?

I wanted to build something that could answer those questions without requiring them to call me every time a message looked confusing or urgent.

So I built ApnaSahayak.

The workflow is deliberately simple:

Paste a message → Understand it → Know what to do → Stay safe

Demo

For example, I can give ApnaSahayak a message like:

URGENT! Your bank account will be blocked today.
Verify your account immediately by clicking this link
and entering your OTP.

Instead of simply summarizing the message, ApnaSahayak breaks it down into three things:

What is this?

It explains the message in simple English.

What should I do?

It gives the user a practical next step.

Safety

It highlights risks such as requests for OTPs, passwords, PINs, banking credentials, suspicious links, or urgent payment requests.

The goal isn't to replace a bank or security professional. The goal is to give my parents a calm first explanation and encourage them to verify important requests through official channels.

Code

akshat-jjain / apnasahayak

A private digital helper for parents powered by local open-weight AI.

🏠 ApnaSahayak

A private digital helper for parents.

ApnaSahayak helps parents understand confusing digital messages, know what to do next, and spot potential safety risks.

It is intentionally small: paste a message, let the local AI explain it, and get three clear answers:

What is this?
What should I do?
Safety

Why I built it

I built ApnaSahayak for my parents.

Digital messages from banks, payment services, delivery companies, account providers, and other services can be difficult to interpret quickly. A parent may not know whether a message is important, what action is required, or whether a link is safe.

The goal is simple:

Instead of calling me every time a confusing message arrives, they can ask ApnaSahayak first.

What makes it different

ApnaSahayak uses a local open-weight AI model rather than requiring a cloud AI API.

The application runs:

Parent's message
       ↓
ApnaSahayak
       ↓
Ollama
       ↓
Qwen3 4B
       ↓

…

View on GitHub

How I Built It

The application uses:

Python
Streamlit
Ollama
Qwen3 4B The architecture is intentionally simple:

Parent's message
       ↓
ApnaSahayak
       ↓
Ollama
       ↓
Qwen3 4B
       ↓
Structured local response
       ↓
What is this?
What should I do?
Safety

The model returns a small structured response instead of generating an unrestricted answer. The application then controls how that information is presented.
For example, the model returns:

{
  "what_is_this": "...",
  "what_should_i_do": "...",
  "safety": "..."
}

This keeps the AI responsible for understanding the message while keeping the user experience predictable.

Why Does Open Innovation Matter?

This is probably the most important technical decision in the project.
Messages from parents can contain sensitive information:

bank notifications
transaction information
account alerts
personal messages
payment information

I didn't want the default architecture to require sending those messages to a third-party AI service.
ApnaSahayak uses an open-weight model through local inference.
The model runs through Ollama on the user's own computer:

User's message
     ↓
Local application
     ↓
Ollama
     ↓
Qwen3 4B
     ↓
Local response

That means the application does not need a cloud AI API to understand the message.

For this particular use case, that matters more to me than simply using the largest available model.

Open models also give me control over the AI layer. I can change the model, modify the system instructions, change the inference setup, or experiment with a different open-weight model without redesigning the entire application around one proprietary API.

The open approach therefore isn't an implementation detail.
Privacy and control are part of the product.

Why I Built It for My Parents

I didn't want to build another generic chatbot.

I wanted to solve a small problem that actually exists in my family.

When someone receives a message saying:

"Your account will be blocked today!"

the natural reaction is urgency.

ApnaSahayak is designed to slow that reaction down:

Understand first. Act second.

That is the behavior I wanted the product to encourage.

Safety

ApnaSahayak is intentionally conservative around sensitive information.
The model is instructed to:

never request OTPs, PINs, passwords, CVVs, or banking credentials
warn about suspicious links
highlight unexpected payment requests
avoid claiming that a message is definitely legitimate
avoid claiming that something is definitely a scam when the evidence isn't sufficient
recommend verifying important requests through official channels

This isn't intended to be a security product.

It is a safety-oriented explanation layer for people who may not immediately understand a digital message.

What I Learned

The biggest lesson was that a useful AI product doesn't need to be large.
The first version of ApnaSahayak only does one thing:

Help my parents understand a confusing message safely.

Running the model locally made the privacy story much clearer, and using a small open-weight model forced me to keep the experience focused instead of hiding behind a large general-purpose API.