Week2 Challenge(Touch_grass)

What I Built

Touch Grass is a desktop wellness and focus companion designed to help people step away from their screens and spend more time in the real world.

The app monitors active screen time and detects when someone has been focused on their computer for too long. Instead of showing another generic reminder, it guides the user through a break experience and recommends nearby outdoor places or activities where they can reset.

The app is designed for:

• Developers and remote workers
• Students
• People who spend long hours at a computer
• Anyone trying to build healthier screen-time habits

Touch Grass includes:

• Active screen-time tracking
• Break-threshold detection
• Desktop notifications
• Outdoor and break recommendations
• Map-based recommendation views
• A dashboard for activity history
• Configurable break settings
• Privacy and settings screens
• A native desktop experience rather than only a browser-based reminder

The goal is simple: make it easier to notice when you have been sitting at a screen too long and take a meaningful break before burnout sets in.

Demo

Because Touch Grass uses Tauri and Rust functionality for desktop activity tracking, the best demonstration is a short video showing:

1. The main focus screen
2. Screen-time tracking in action
3. A break recommendation being triggered
4. An outdoor recommendation appearing
5. The map view and settings experience

Code

GitHub repository:

https://github.com/RathnamS089/touch_grass

The project is built as a Tauri desktop application with a React and TypeScript frontend and a Rust backend.

How I Built It

Touch Grass is built with:

• React
• TypeScript
• Vite
• Tauri 2
• Rust
• Tailwind CSS
• SQLite
• Supabase
• Leaflet
• Vitest
• Playwright

The frontend manages the user experience, navigation, settings, dashboard, break flow, and recommendation screens.

The Rust and Tauri backend handles native desktop functionality, screen-time tracking, activity sessions, break thresholds, notifications, and communication with the frontend through Tauri events.

The application listens for events such as break_ready and recommendation_ready. When the backend detects that a user has been on screen for too long, it sends a recommendation event to the React frontend. The frontend then transitions into a break experience and displays a suggested outdoor place.

The application is structured so that the screen-time engine remains the source of truth rather than trying to estimate activity only from frontend timers.

Open-source AI

AI Used in the Application

Qwen3:4B runs locally through Ollama as part of the backend recommendation system.

The model helps select a relevant outdoor location from nearby candidates while considering variety, distance, and places the user has already seen. Running Qwen3:4B locally means the recommendation workflow does not require a proprietary hosted AI API for every request.

Z.ai GLM 5.3 Flash was used as the coding and development assistant while building Touch Grass.

It helped with:

• Planning the application architecture
• Designing the React and Tauri integration
• Implementing frontend and Rust backend features
• Debugging event-driven break flows
• Improving the screen-time tracking experience
• Refining the recommendation interface
• Reviewing and iterating on code

The development model and the runtime model serve different purposes: GLM 5.3 Flash supported the coding process, while Qwen3:4B powers the local recommendation experience inside the application.

Using a locally hosted model also made the project more privacy-conscious and easier to experiment with. The AI layer can be developed, tested, and replaced independently from the rest of the desktop application.

The project combines local AI inference with a native Tauri and Rust application. This makes it possible to connect screen-time awareness, user preferences, and break recommendations while keeping the system transparent and extensible.

For example:

I used [model/framework name] as part of the development process to help explore the product idea, design the break recommendation experience, reason about the application architecture, and iterate on the user flow. The project keeps the AI-assisted parts transparent and replaceable rather than hiding them behind a proprietary API.

If the application itself does not currently use an AI model at runtime, it is safer to say:

The current version focuses on the activity-tracking and recommendation experience. AI was used during development and iteration through an open-source agentic workflow, while the core desktop application remains locally controlled and does not require a proprietary AI API to run.

Why Does Open Innovation Matter?

Open innovation made it possible to use AI both during development and inside the application without depending entirely on closed, hosted platforms.

Touch Grass uses Qwen3:4B through Ollama in its Rust backend to generate outdoor break recommendations. Because the model runs locally, the recommendation workflow can be inspected, adapted, and developed without sending every request to a proprietary AI service.

I also used Z.ai GLM 5.3 Flash as a coding assistant during development. This made it possible to iterate quickly on the application architecture, connect the React frontend with the Rust and Tauri backend, debug event-driven flows, and improve the user experience.

Open technologies and open-weight models gave me more control over:

• How the AI recommendation system works
• Where user-related activity data is processed
• Which model is used at runtime
• How the backend communicates with the frontend
• How the project can be modified or extended
• How other developers can reproduce and contribute to the project

For a wellness application, local and inspectable AI is especially valuable. Screen-time and activity data can be sensitive, so keeping the recommendation model available through Ollama provides a more privacy-conscious alternative to relying only on a closed API.

The project demonstrates two sides of open innovation: an open-weight local model powering the product, and an AI coding assistant helping build and improve the software.

My Agent Session

check my github repo,havent actively updated my agent sessions to record.

The agent session documents how the application was planned, implemented, debugged, and refined. It shows the reasoning behind the desktop architecture, the break-trigger flow, and the connection between the Rust backend and React frontend.