DEV Community: Layton Tozvireva

🌿 GrassQuest — An Open-Weight AI Adventure Generator That Gets You Outside

Layton Tozvireva — Tue, 06 Oct 2026 15:42:44 +0000

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

🎯 What I Built

For Hacktoberfest 2026 Week 1, I built GrassQuest, an AI-powered outdoor mission generator designed to help people spend less time on screens and more time outside.

The idea is simple:

Tell GrassQuest how much time you have, what kind of outdoor activity you prefer, and your energy level — and it creates a short outdoor mission for you.

Users can choose from different time durations, outdoor activities, and energy levels. GrassQuest then generates a personalized adventure with a title, duration, five simple steps, and a safety reminder.

The user can then put their phone away, go outside, complete the challenge, and return afterward to record a reflection in their personal journal.

The goal is for the screen to be the shortest part of the experience.

🤖 Why Open-Weight AI?

Open innovation is at the heart of GrassQuest.

GrassQuest uses Gemma, an open-weight AI model, through Ollama for local mission generation.

Instead of depending entirely on a closed AI API, I built the application around an open-weight model that I can run locally and control through my own prompts and application logic.

This gives the project:

🔓 More control over the AI
💻 Local inference
🧩 The ability to experiment with different models
💰 Less dependence on paid API calls
🛠️ More control over prompting and AI behavior

For this challenge, I wanted the AI itself to be an important part of the application rather than simply adding AI as a feature on top of an existing idea.

🌿 How GrassQuest Works

The user selects three preferences:

⏱️ Time

15 minutes
30 minutes
45 minutes
60 minutes

🌳 Activity

Nature
Walking
Photography
Mindfulness
Exploration

⚡ Energy

Relaxed
Normal
Active

These preferences are sent to the GrassQuest backend, which creates a structured prompt for Gemma.

Gemma is instructed to return a structured outdoor mission containing:

A mission title
Duration
Five steps
A safety reminder

The application then presents the result as an Adventure Plan.

🛡️ Safety Validation

Because GrassQuest encourages people to go outside, I didn't want the AI to generate unrestricted activities.

I added a safety validation layer to the backend.

Generated missions are checked for potentially unsafe instructions such as:

Climbing
Swimming
Crossing roads
Entering private property
Touching wildlife
Touching unknown plants
Eating wild plants

If an AI-generated mission fails the safety check, GrassQuest uses a predefined safe fallback mission instead.

This creates an additional safety layer between the AI output and the user.

🔌 AI + Fallback System

I also wanted GrassQuest to remain useful when the AI model isn't available.

The application therefore has a fallback mission system.

When Gemma/Ollama is available:

User → GrassQuest → Gemma → Safety Validation → Outdoor Mission

If the AI is unavailable:

User → GrassQuest → Safe Fallback Engine → Outdoor Mission

This means the core outdoor experience doesn't have to completely stop when the AI service isn't running.

📖 Outdoor Journal

After completing an adventure, users can write a reflection.

GrassQuest stores these reflections locally in the browser, allowing users to build a simple record of their outdoor experiences.

The experience becomes:

Choose → Generate → Go Outside → Complete → Reflect

The journal isn't designed to keep users scrolling. It's there to help them remember the experiences they had away from the screen.

🧑‍💻 Tech Stack

GrassQuest was built with:

React
JavaScript
Tailwind CSS
Node.js
Express
Gemma
Ollama
localStorage
Git & GitHub

📱 Built Around the "Touch Grass" Idea

There is an interesting challenge when building an application about spending less time on screens:

The application itself is a screen.

So I designed GrassQuest around a short interaction.

The user:

Chooses their preferences.
Generates a mission.
Reads the instructions.
Puts the phone away.
Goes outside.
Completes the mission.
Returns to record their experience.

The objective isn't to keep someone inside the application.

It's to give them a reason to leave it.

💡 Why I Built This

Technology is extremely good at capturing our attention.

I wanted to experiment with the opposite idea:

What if AI helped us use our screens less?

Instead of generating another recommendation for something to watch or another thing to scroll through, GrassQuest generates a reason to step outside.

A 15-minute walk, a short nature observation session, or a simple mindfulness activity can become a small step toward spending more time in the physical world.

🏆 Hacktoberfest Categories

GrassQuest is especially relevant to:

🌿 Touch Grass

The core purpose of GrassQuest is to use technology to encourage people to spend time outdoors.

🤖 Best Use of Gemma

Gemma is used as the open-weight model for generating personalized outdoor missions.

The project combines Gemma with:

Structured prompting
JSON output
Application-level safety validation
Fallback logic
A React user interface

This makes the open-weight model part of the core application workflow.

🚀 What I Learned

Building GrassQuest taught me that integrating AI into an application is about much more than sending a prompt to a model.

I had to think about:

Prompt design
Structured AI output
Safety validation
Invalid model responses
AI availability
Fallback systems
User experience
Local storage
Responsive design
Frontend/backend architecture
Using AI for a real-world purpose

The biggest lesson was:

AI should support the experience, not become the experience.

🔮 What's Next?

Some features I would like to explore in the future include:

📍 Location-aware missions
🌦️ Weather-aware recommendations
🐦 Nature and birding missions
📱 Progressive Web App support
🗺️ Outdoor route suggestions
🔄 More interchangeable open-weight models
📊 Outdoor activity statistics
🔐 More privacy-focused local-first features

The long-term goal is to make GrassQuest something people can use quickly before putting their phone away.

🌐 Try GrassQuest

🚀 Live Demo

Launch GrassQuest

💻 Source Code

View GrassQuest on GitHub

🎥 Demo Flow

The GrassQuest experience is:

Select your preferences → Generate an AI mission → Start the adventure → Go outside → Complete the mission → Reflect in your journal

The project was built specifically around the Hacktoberfest Week 1 theme:

Touch Grass.

And that's exactly what I want GrassQuest to encourage.

❤️ Final Thoughts

This project started with a simple question:

Can we use AI to help people spend less time using technology?

GrassQuest is my attempt at answering that question.

Instead of asking AI what to watch next, what to read next, or what to scroll through next, GrassQuest asks:

"What can I do outside right now?"

🌿 Generate less screen time. Experience more real life.

Hacktoberfest #DEVChallenge #hf26challenge #OpenSource #AI #Gemma #Ollama #React #JavaScript #TouchGrass #SoftwareDevelopment

InterviewBuddy — An AI Interview Practice Partner

Layton Tozvireva — Sun, 04 Oct 2026 15:20:25 +0000

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

What I Built

I built InterviewBuddy, an AI-powered interview practice partner for friend who feel nervous or unprepared for job interviews.

Instead of being a general-purpose chatbot, InterviewBuddy simulates a real interview. The user provides the job title, job description, background, interview type, and nervousness level. The AI then asks interview questions one at a time and uses the conversation context to make the interview progressively more realistic.

After the interview, InterviewBuddy analyzes the complete conversation and provides a structured review covering communication, confidence, technical knowledge, relevance, clarity, problem solving, strengths, weak answers, corrections, and practical tips for the next attempt.

Live Demo

https://interviewbuddy-psi.vercel.app/

GitHub

https://github.com/laytontozvireva-star/Interviewly

Why did you build it?

The idea came from a simple problem.

Someone can have the technical skills and still struggle during an interview because they are nervous, don't know what to expect, or have not had enough opportunities to practice.

Practicing with another person is not always possible.

I wanted to build something that gives a person a safe place to practice repeatedly.

You can make mistakes without embarrassment.

You can try again.

You can see where your answers need improvement.

And eventually, you can walk into a real interview with more confidence.

That is why I did not want to build another general AI chatbot.

I wanted to build an AI practice partner for a specific human problem.

Why open innovation matters

For this project, I wanted the AI to be based on an open-weight model rather than making the application dependent on a closed AI chatbot.

InterviewBuddy uses OpenAI GPT-OSS 20B through Hugging Face Inference Providers.

This showed me an important part of open innovation: developers can take openly available models and build focused solutions around them.

The model itself is not the complete product.

The value comes from how it is used.

In InterviewBuddy, the model becomes an interviewer during the interview and a coach after the interview.

Open models also give developers more freedom to experiment, learn, and create specialized applications.

How does it work?

The application follows this flow:

User → React application → Vercel API → Hugging Face → GPT-OSS 20B → Interview response

During the interview, the application sends the relevant interview context to the AI, including previous questions and answers.

The AI is instructed to behave like a realistic interviewer and return one question at a time.

When the interview is complete, the full interview is sent to the AI coach.

The coach then produces a structured review containing scores, strengths, weaknesses, corrections, and suggestions for improvement.

The application also includes browser-based voice interaction to make the practice experience feel more like an actual interview.

What makes it different?

The main difference is the focus.

InterviewBuddy is not designed to answer random questions.

It is designed around one experience:

helping someone become better at interviews.

The AI has two distinct roles:

During the interview

It behaves like an interviewer.

It asks questions and does not immediately reveal the answer or give feedback.

After the interview

It becomes a coach.

It reviews the complete interview and explains what the candidate can improve.

This separation makes the experience closer to actual interview practice.

Technology

React
JavaScript
Tailwind CSS
Node.js
Vercel Serverless Functions
Hugging Face Inference Providers
OpenAI GPT-OSS 20B
Browser Speech APIs
Git
GitHub

What I learned

The biggest lesson was that building an AI application is not simply about connecting an API.

A large part of the work was designing the AI's behavior.

I had to make the model understand when it should act as an interviewer and when it should act as a coach.

I also learned about:

Prompt design
AI inference
Maintaining conversation context
Serverless API routes
Error handling
Voice interaction
Deploying AI applications
Working with open-weight models

I also learned that a strong AI project should begin with a real problem rather than simply starting with a model and asking what can be built with it.

What's next?

I would like to continue improving InterviewBuddy with:

Interview history
Progress tracking
More personalized coaching
More job-specific interview modes
Better voice interaction
Additional open models
More detailed improvement tracking between attempts

The long-term goal is to make InterviewBuddy something a candidate can return to throughout their job search rather than something they use only once.

Final thought

I started with a simple question:

Can AI help someone become more confident before facing a real interviewer?

InterviewBuddy is my attempt to answer that question.

I didn't build another AI chatbot.

I built an interview practice partner.

PIRS — Public Infrastructure Reporting System

Layton Tozvireva — Tue, 29 Sep 2026 12:18:34 +0000

PIRS — Public Infrastructure Reporting System

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange.

What I Built

PIRS (Public Infrastructure Reporting System) is a civic technology platform designed to help citizens report public infrastructure problems and understand what to do about them.

The idea started with a simple question:

What if reporting a pothole, water problem, sewer blockage, electricity fault, or broken traffic light could be easier and more informative?

Instead of simply submitting a complaint and forgetting about it, PIRS connects three parts of the experience:

REPORT → LOCATE → TRACK

A citizen can report an infrastructure problem, provide its location and supporting information, and then track the report.

I also wanted PIRS to go beyond being a reporting form.

The platform includes a Knowledge Center containing structured infrastructure information and an AI Assistant that uses that knowledge to help citizens understand infrastructure problems and reporting procedures.

The application currently covers infrastructure categories including:

Electricity
Water
Sewer
Roads
Traffic Lights
Illegal Dumping
Fallen Trees
Other

The goal was to create something that feels like a real civic technology product rather than just a form submission project.

Demo

Live application:
https://public-infrastructure-reporting-sys.vercel.app/

The application includes:

Home
Report Issue
My Reports
Knowledge Center
AI Assistant
Login and Registration

The AI Assistant can answer questions such as:

How do I report a water problem?
What information should I provide when reporting an electricity fault?
Who should I contact about a damaged road?
What should I do if I see a blocked sewer?

The answers are grounded in infrastructure knowledge stored in Sanity rather than being generated from an empty prompt.

Screenshots

Home

The landing page introduces the reporting workflow and makes the REPORT, LOCATE and TRACK concept central to the experience.

Report Issue

The reporting interface allows citizens to select an infrastructure category, describe the problem, provide a location and attach supporting information.

My Reports

Citizens can view the issues they have submitted and follow their current status.

Knowledge Center

The Knowledge Center presents structured infrastructure information organized by category.

AI Assistant

[INSERT AI ASSISTANT SCREENSHOT]

The AI Assistant uses the PIRS knowledge stored in Sanity to provide grounded infrastructure guidance.

Code

GitHub repository:
https://github.com/laytontozvireva-star/Public_Infrastructure_Reporting_System

The project is built as a React application with Tailwind CSS and Supabase, with Sanity powering the structured infrastructure knowledge layer.

My Build Process

This project was built iteratively rather than from a finished specification.

I started with the original PIRS concept: a platform where citizens could report infrastructure problems such as electricity faults, water problems, sewer blockages, potholes and broken traffic lights.

The first version focused primarily on the reporting experience.

As the project developed, I realized that reporting alone was not enough. A citizen might know that something is broken but still not know:

Who is responsible?
What information should be provided?
What safety precautions should be taken?
How should the problem actually be reported?

That led me to add a structured knowledge layer using Sanity.

Step 1 — Designing the reporting experience

The first goal was to make reporting simple.

I created the main reporting flow around:

Category → Description → Location → Photo → Submit

The application uses Supabase for authentication, database storage and report photos.

The infrastructure categories were also designed to match the types of public problems PIRS is intended to handle.

Step 2 — Introducing Sanity

I then created a Sanity project specifically for PIRS infrastructure knowledge.

Instead of storing everything as unstructured text, I created a structured infrastructureKnowledge document type.

The schema contains fields such as:

Title
Category
Problem
Safety guidance
Reporting procedure
Required information
Responsible authority
Location context
Summary
Source name
Source

This became an important change in the architecture.

The knowledge was no longer just text displayed on a page. It became structured content that the application could query and use.

Step 3 — Collecting infrastructure knowledge

I started adding real infrastructure information from relevant Zimbabwean sources.

For example, the knowledge base contains information related to organizations and services such as ZINWA, ZESA and City of Harare services.

The source material was transformed into structured PIRS knowledge records rather than simply copied into frontend components.

This means the application can retrieve information by category and the AI layer can work with the structured fields.

Step 4 — Building the Knowledge Center

After the Sanity content was available, I built the Knowledge Center in the React application.

The frontend retrieves infrastructure knowledge from Sanity and presents it in a citizen-friendly interface.

This created a second major experience inside PIRS:

Report an issue → Learn about the issue

Step 5 — Adding the AI Assistant

The next step was connecting Gemini to the structured PIRS knowledge.

The AI assistant does not simply receive the user's question and generate an unrestricted answer.

The backend first retrieves the available infrastructure knowledge and identifies records that are relevant to the question.

Those records are then provided to Gemini with instructions to:

Use only the supplied PIRS knowledge
Avoid inventing authorities or procedures
Avoid inventing contact information
Prioritize safety
Clearly state when the available knowledge is insufficient
Preserve the supplied source information

This was important because infrastructure reporting can involve safety issues and incorrect contact information could make the system less useful.

Step 6 — Debugging real problems

The build was not completely smooth.

One of the biggest problems appeared when the Gemini API started returning HTTP 429 responses because the free-tier request quota had been reached.

Initially, the frontend displayed a generic connection error.

I traced the problem through the production logs and found that the actual backend response was a Gemini quota error.

I then changed the backend to return a clear 429 response when the quota is exceeded and changed the frontend to preserve and display the backend error message.

That turned a vague:

Unable to connect to the PIRS knowledge assistant.

into a useful message explaining that the AI service had reached its daily limit.

I also added retry handling for temporary Gemini service errors.

This was one of the most useful parts of the build because it showed me that getting an AI feature working is only one part of the problem. Handling failure states matters just as much.

What worked

The final architecture became:

Citizen
   ↓
React + Tailwind PIRS
   ↓
┌───────────────────────┐
│                       │
│   Supabase            │
│   Reports + Auth      │
│   Photos              │
│                       │
└───────────────────────┘

   +

┌───────────────────────┐
│                       │
│   Sanity              │
│   Infrastructure      │
│   Knowledge           │
│                       │
└───────────────────────┘
            ↓
      Relevant Knowledge
            ↓
          Gemini
            ↓
     PIRS AI Assistant

The combination of structured content and an AI interface made the Knowledge Center much more useful than a collection of static articles.

Sanity Project Details

Sanity Project ID: wenswj4d

Dataset: production

The main Sanity document type is:

infrastructureKnowledge

The schema was created specifically for PIRS and contains structured fields for infrastructure categories, safety guidance, reporting procedures, responsible authorities and source information.

Sanity is therefore not just being used as a generic CMS.

It acts as the structured knowledge layer behind the Knowledge Center and AI Assistant.

Technical Stack

Frontend

React
React Router
Tailwind CSS
React Markdown
Lucide React

Backend / Data

Supabase
Sanity Content Lake
GROQ

AI

Google Gemini API

Deployment

Vercel

Development

VS Code
Git
GitHub

What I Learned

Building PIRS taught me several things about combining structured content with AI.

1. Structured content changes what an AI application can do

Instead of giving an AI model a completely open-ended prompt, I can provide it with a defined body of infrastructure knowledge.

That makes the application's behavior easier to control.

2. Schema design matters

The Sanity schema determines what information is available to the application.

Fields such as responsibleAuthority, safetyGuidance, reportingProcedure and requiredInformation give the AI and frontend meaningful structure to work with.

3. AI features need failure handling

The Gemini quota problem was a good reminder that an AI API can fail even when the application itself is working correctly.

The application therefore needs proper handling for:

Rate limits
Temporary service failures
Missing API keys
Missing knowledge
Invalid questions
Backend errors

4. The product should come before the AI

The AI Assistant became more useful after the underlying PIRS product and knowledge model were defined.

The AI is not the entire product.

It is one part of a larger civic reporting experience.

Why I Built PIRS

Infrastructure problems are often visible to citizens long before they are formally reported.

A fallen pole, leaking pipe, pothole, blocked sewer or broken traffic light can affect an entire community.

PIRS explores how software can make the process of reporting these problems more accessible while also helping citizens understand what information they need to provide.

The project started as a reporting system.

It evolved into a combination of:

Civic Reporting + Structured Knowledge + AI Assistance

That evolution is what made the project especially interesting to build.

Final Thoughts

PIRS started as a simple idea:

See a problem → Report it → Provide the location → Track it

While building it, the project became much larger.

Sanity gave the application a structured infrastructure knowledge layer, while Gemini provided a conversational interface over that knowledge.

The result is a civic technology platform that combines reporting, location, tracking, structured content and AI assistance in one experience.

This submission represents the actual build process, including the problems, debugging and architectural decisions that happened along the way.

sanitychallenge #devchallenge #sanity #ai

PIRS — Public Infrastructure Reporting System

Layton Tozvireva — Tue, 29 Sep 2026 12:00:04 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

PIRS — Public Infrastructure Reporting System

What I Built

I built PIRS (Public Infrastructure Reporting System), a civic technology platform designed to help citizens report and understand public infrastructure problems in their communities.

People can encounter issues such as:

Electricity faults
Water problems
Blocked sewer systems
Potholes and damaged roads
Broken traffic lights
Illegal dumping
Fallen trees

PIRS gives citizens a way to report these problems, provide their location and supporting information, and track submitted reports.

For the Sanity Challenge, I extended PIRS with a structured Infrastructure Knowledge Base and AI assistant.

Instead of asking the AI to answer infrastructure questions purely from general knowledge, the assistant retrieves relevant structured PIRS knowledge from Sanity and uses that information as context for its response.

Demo

Live application:
https://public-infrastructure-reporting-sys.vercel.app/

The Knowledge page contains the Infrastructure Knowledge Base and AI assistant.

Example questions include:

How do I report a water problem?

Who should I contact about a damaged road?

What information should I provide when reporting an electricity fault?

The application also provides a directory of the underlying infrastructure knowledge and links to source information.

Code

GitHub repository:
https://github.com/laytontozvireva-star/Public_Infrastructure_Reporting_System

How I Used Sanity

Sanity is used as the structured knowledge layer behind the PIRS infrastructure assistant.

I created a Sanity project with a dedicated infrastructureKnowledge document type.

Each knowledge record can contain structured information such as:

Title
Infrastructure category
Problem
Safety guidance
Reporting procedure
Required information
Responsible authority
Location context
Summary
Source name
Source URL

The categories include:

Electricity
Water
Sewer
Roads
Traffic Lights
Illegal Dumping
Fallen Trees
Other

The knowledge base contains infrastructure information collected from relevant sources, with source information preserved alongside the structured records.

The PIRS backend queries the Sanity Content Lake and retrieves the infrastructure knowledge used by the assistant.

The AI assistant then performs relevance matching against the structured content before providing the relevant knowledge as context to Gemini.

The assistant is instructed to:

Use only the provided PIRS knowledge.
Avoid inventing authorities, procedures, phone numbers, or other facts.
Prioritize safety information where applicable.
State when the available knowledge is insufficient.
Preserve the relationship between the answer and the underlying source information.

This makes Sanity the structured knowledge layer that the PIRS AI assistant depends on.

Sanity Project Details

Sanity Project ID: wenswj4d

Dataset: production

The project contains the infrastructureKnowledge schema and published infrastructure knowledge records used by the PIRS application.

Technical Stack

Frontend

React
React Router
Tailwind CSS
React Markdown
Lucide React

Backend / Services

Vercel serverless API routes
Sanity
Supabase
Google Gemini

Core flow

Citizen question
      ↓
PIRS AI Assistant
      ↓
Sanity structured knowledge
      ↓
Relevant infrastructure records
      ↓
Gemini
      ↓
Grounded response
      ↓
Source information displayed to the citizen

The main PIRS reporting system also uses Supabase for authentication, reports, and report photos.

What I Learned

The biggest lesson from this project was that an AI assistant becomes much more useful when the information it relies on is structured and traceable.

Instead of treating infrastructure information as one large block of text, I modeled important parts of each issue separately: category, authority, reporting procedure, safety guidance, required information, location context, and source.

That structure made it possible for the application to retrieve relevant knowledge and give the AI a focused context for answering questions.

I also encountered real production issues during development, including temporary Gemini service errors and free-tier quota exhaustion. I added explicit handling for these conditions so users receive a meaningful service-limit message instead of a generic connection failure.

Why PIRS

Infrastructure problems are easy to see but often difficult to report correctly.

A citizen may know that a road is damaged or that a water pipe is leaking, but may not know:

Who is responsible?
What information should be provided?
Where should the problem be reported?
What safety precautions are necessary?

PIRS brings reporting, location, tracking, structured infrastructure knowledge, and an AI assistant into one civic technology experience.

The goal is simple:

Report. Locate. Track.