DEV Community: anmolchaudhary617-ux

Touch Grass: An Open-Source AI That Sends You Outside

anmolchaudhary617-ux — Sun, 11 Oct 2026 18:29:18 +0000

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

Touch Grass: Less Screen Time, More Real-World Adventures

What if AI didn't try to keep you staring at a screen—but actually encouraged you to put your phone away?

That's the idea behind Touch Grass, an AI-powered outdoor adventure application I built for the Hacktoberfest Open-Source AI Challenge.

Instead of endlessly scrolling, users choose an adventure style, pick how much time they have, and let AI generate a mission that encourages them to explore their surroundings.

The goal is simple: use technology to help people spend less time using technology.

What I Built

Touch Grass turns an ordinary walk into an opportunity for discovery.

Users can choose from three adventure styles:

Investigate: Follow clues and uncover details.
Observe: Slow down and notice nature.
Discover: Find something unexpected.

They also choose an adventure duration, ranging from 10–15 minutes to 30–45 minutes.

The application generates a mission with a premise, an objective, a safety briefing, and a first clue. Once the adventure begins, users can put their phones away, explore their surroundings, return to record observations, and receive their next AI-generated clue.

The experience is designed around a simple principle: the screen should be the shortest part of the adventure.

A Look at Touch Grass

1. Plan Your Adventure

Choose how you want to explore and how much time you have. The interface is designed to make starting an adventure straightforward.

Caption: First look of the home screen.

2. Generate a Mission

The AI creates an outdoor mission tailored to the selected adventure style and duration, giving users a starting point for their exploration.

Caption: Each mission includes an objective and an initial clue to get the adventure started.

3. Explore, Observe, and Discover

After receiving the first clue, users are encouraged to put their phones away and observe their surroundings. When they return, they can describe what they noticed and request the next clue.

Caption: Progressive clues help turn real-world observations into an interactive adventure.

How I Built It

I built Touch Grass using a React frontend, a Python backend, and locally running open-weight AI.

Technology stack

React + Vite: Frontend and interactive adventure interface.
Python + FastAPI: Backend API and mission-generation workflow.
Ollama: Local model inference.
Qwen3 4B: The open-weight language model powering AI-generated missions and clues.
Pytest: Backend testing.

The backend handles mission requests and generates follow-up clues based on the user's observations. I also implemented clue-progression logic so the experience can move through different stages of exploration.

One of the challenges was making language-model output predictable enough for an application. AI responses can vary in structure, so I worked on normalizing responses, validating expected fields, and testing clue progression.

At the time of submission, the backend test suite passes 33 tests, and the frontend production build succeeds.

Why Does Open Innovation Matter?

For Touch Grass, open innovation wasn't just a technology choice. It changed how I could build and experiment with the project.

Using Ollama and Qwen3 4B allowed me to run inference locally instead of making a paid, proprietary AI API a required dependency.

That gave me several advantages:

1. More control over the AI experience

I can experiment with prompts, adjust the mission-generation process, and explore different models without redesigning the entire application around one proprietary provider.

2. Local inference

The model can run on a compatible local machine, allowing experimentation without sending every prompt to a third-party inference API. The initial model download and setup still require the appropriate installation and model files.

3. Lower dependency on paid APIs

For a student project, avoiding a mandatory paid inference API makes experimentation more accessible and removes usage-based API charges from the core development workflow. Local inference still uses the computer's resources.

4. A more open development path

Other developers can inspect the code, experiment with the prompts, change the model, and build on the idea.

I especially like that the technology can be used to encourage people to disconnect. AI provides the initial guidance, but the actual experience happens outside the application—in the world around the user.

What I Learned

Building Touch Grass taught me that integrating AI into an application involves more than calling a model and displaying its response.

I had to think about structured output, API validation, clue progression, frontend state, error handling, and testing. I also learned how important it is to keep the interface focused on the user's real-world goal instead of adding unnecessary screen interactions.

There is still room to improve the experience, particularly through more field testing, refining mission progression, and eventually making the app easier to access outside a local development environment.

My Agent Session

I used AI-assisted development tools while building and debugging the project.

What's Next?

I'd like to continue improving Touch Grass with better mission variety, more reliable clue progression, and feedback from people actually using it outdoors.

The most important test isn't whether someone spends more time inside the app. It's whether the app gives them a reason to close it, step outside, and discover something they might otherwise have missed.

Try the Project

GitHub repository: Touch Grass — anmolchaudhary617-ux/touch-grass

The project currently runs locally. A public deployment is not available yet.

If you try the idea, I'd love to hear what kind of outdoor mission would get you to put your phone away and explore.

Build with open AI. Step away from the screen. Touch Grass.

# VivaMate — An AI Viva Partner Built for a Friend

anmolchaudhary617-ux — Sat, 03 Oct 2026 22:03:45 +0000

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

What I Built

VivaMate is an AI-powered viva practice platform I built for a friend who has to prepare for technical university vivas.

The problem was simple: studying from notes is one thing, but actually answering questions and getting meaningful feedback is another. Finding someone who is always available to conduct a mock viva is not always practical.

So I built VivaMate to act as an on-demand viva practice partner.

You can:

Upload your study material as a PDF or TXT file
Generate viva questions based on your material
Choose the number and difficulty of questions
Take a one-question-at-a-time mock viva
Submit answers for AI evaluation
Receive a score, feedback, ideal answer, and follow-up question
View a final performance report showing strengths and areas to improve

The goal isn't to replace a professor or a real viva. It's to give a student a way to practice repeatedly before the real thing.

Demo

🌐 Live Demo

VivaMate is deployed with a React/Vite frontend on Vercel and a FastAPI backend on Render.

Flow:

Study Material → Question Generation → Mock Viva → AI Evaluation → Performance Report

Code

The complete source code is available on GitHub:

VivaMate GitHub Repository

How I Built It

VivaMate is built around open-weight AI rather than making a proprietary AI API the core of the application.

The core model is Qwen3 4B.

During local development, I run Qwen3 4B locally through Ollama. This allowed me to develop and test the AI workflow directly on my own machine.

The local architecture is:

React + Vite
↓
FastAPI
↓
AI Service Layer
↓
Ollama
↓
Qwen3 4B

For the deployed version, the same AI service abstraction allows the application to use Hugging Face Inference Providers with Qwen3 4B.

The production architecture is:

Vercel
↓
React + Vite
↓
Render
↓
FastAPI
↓
AI Service Layer
↓
Hugging Face Inference Providers
↓
Qwen3 4B

I deliberately kept the AI integration behind a service abstraction so the application isn't tightly coupled to a single model or inference implementation.

The main technologies are:

React + Vite
FastAPI
Python
Ollama
Qwen3 4B
Hugging Face Inference Providers
Pydantic
PyPDF
HTML/CSS/JavaScript

The AI is used for two important parts of the application:

1. Viva Question Generation

Given a topic or uploaded study material, Qwen3 generates structured viva questions with difficulty levels.

When study material is provided, the generated questions are instructed to stay grounded primarily in that material.

2. Answer Evaluation

After the student answers a question, Qwen3 evaluates the response and returns:

Score out of 10
Correctness level
Educational feedback
Ideal answer
Follow-up question

The application doesn't expose the model's internal reasoning. It only uses the structured evaluation needed by the student.

What the Experience Looks Like

VivaMate is designed around a simple practice loop:

Upload → Generate → Answer → Evaluate → Improve

The student answers each question one at a time and receives structured feedback from Qwen3 4B, including a score, correctness assessment, ideal answer, and a follow-up question.

At the end of the session, VivaMate summarizes performance and highlights areas that need further practice.

Why Does Open Innovation Matter?

For VivaMate, open innovation isn't just a technology choice. It changes what the project can be.

Because Qwen3 4B can run locally through Ollama, I could build and test the complete AI workflow on my own machine without making a proprietary cloud AI API a mandatory part of the development setup.

That matters for a study tool because uploaded material can contain personal notes, assignments, or course content.

With local inference, the development version can process the AI requests on the student's own machine rather than requiring every request to be sent to a proprietary AI service.

Open-weight models also give the project flexibility.

VivaMate's AI service is separated from the rest of the application, so the model or inference provider can be changed without rewriting the entire viva system.

For me, the biggest difference was that I wasn't simply building a UI around someone else's AI API. I was able to build the actual learning workflow around an AI model that I could run and experiment with locally.

My Agent Session

I used Google Antigravity as a coding agent while building VivaMate.

The agent helped me implement and verify the React frontend, FastAPI backend, AI integration, document extraction, structured AI responses, mock viva flow, and performance report.

I did not use a DevRelay agent-session link for this submission.

Built for a Friend ❤️

VivaMate started with a simple idea:

Instead of telling my friend to "practice more," why not build them something they can actually practice with?

That became VivaMate.