DEV Community: Vanihba

lost & found!

Vanihba — Mon, 12 Oct 2026 04:48:06 +0000

LOST & FOUND — Disconnect to Rediscover 🌿

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

What I Built

What if AI didn't ask you to spend more time looking at a screen, but helped you discover a reason to put it down?

That's the idea behind LOST & FOUND — an offline-first outdoor exploration app designed to turn an ordinary walk into a small adventure.

We spend so much time scrolling through other people's experiences that we sometimes forget to notice our own surroundings. A familiar street becomes invisible. A tiny plant growing through concrete goes unnoticed. The details that make a place unique disappear into the background of our routines.

LOST & FOUND is my attempt to change that.

Instead of giving you another endless feed, it helps you find an adventure. Choose your mood, available time, and preferred difficulty, then use the app to explore your surroundings with a different perspective.

Your mission might encourage you to:

Find something growing where it shouldn't be able to grow.
Notice a detail on your usual route that you've never paid attention to.
Discover a pattern in the architecture around you.
Find evidence of nature reclaiming a small piece of the city.
Record a tiny discovery that would normally go unnoticed.

The experience is built around one simple idea: you don't need to travel far to discover something new. Sometimes, you just need a different way of looking.

LOST & FOUND also includes a local journal for saving discoveries, an offline-first app shell, and a local AI engine integration designed to generate personalized missions on-device.

It's for curious people, students, solo walkers, and anyone who wants to reconnect with the physical world without turning outdoor exploration into another social media competition.

The goal isn't to collect screen time. It's to collect moments.

Demo

The app is currently being developed and tested locally.

Local development: http://localhost:5173/
Production preview: http://localhost:3000/

These are local addresses, not publicly accessible demo links. I'll add a deployed demo or a recorded walkthrough here when one is available.

Code

Project: LOST & FOUND

GitHub repository: [Add your public GitHub repository URL here]

The project is built with React, TypeScript, Vite, and Tailwind CSS. It includes a mobile-oriented navigation experience, a locally persisted journal using IndexedDB, and a progressive web app foundation.

The codebase is organized into separate pages, components, data, and services so that the interface, journal, and AI engine can evolve independently.

How I Built It

I wanted local AI to be more than a feature added to an ordinary app. It needed to support the central purpose of the project: helping someone explore without depending on a constant internet connection.

The stack

React + TypeScript — the app interface and core application logic.
Vite — development and production builds.
Tailwind CSS — the visual design system.
IndexedDB — local storage for journal entries.
Progressive Web App (PWA) — an installable app foundation with a service worker and cached application assets.
WebLLM — the browser-based local inference runtime being integrated for on-device mission generation.
Llama 3.2 1B Instruct — the open-weight model selected for the current WebLLM implementation, subject to successful runtime and device testing.

The interface uses a field-journal-inspired visual identity: deep forest greens, warm paper tones, moss accents, and a restrained trail-amber highlight. I wanted the experience to feel like opening a personal explorer's notebook rather than another productivity dashboard.

Building honestly for offline use

One important lesson from this project is that an offline interface and an offline AI are two different things.

Caching the app shell can let the interface load without a connection. IndexedDB can keep journal entries on the device. But neither guarantees that a language model is available or capable of generating a new mission offline.

The current implementation separates sample mission previews from actual AI-generated results. If local inference is unavailable or fails, the app should report the failure rather than silently presenting a sample as AI output.

The intended workflow is to download the required model assets while connected, initialize the local inference engine, and then test fresh mission generation with the network disabled.

I'm treating real offline inference as a capability that must be demonstrated on the target device—not something I can claim just because the app builds successfully.

Why Does Open Innovation Matter?

For this project, open innovation is about who controls the experience and where the intelligence runs.

A closed, cloud-only AI API would make it easier to produce personalized missions, but it would also make the core experience dependent on a remote service, connectivity, and potentially usage limits.

An open-weight model and a local inference runtime offer a different direction:

More privacy: exploration preferences and personal reflections can remain on the device when the implementation is configured to use local processing.
Less dependence on connectivity: after the necessary assets are installed and local inference works, the experience can be designed to continue without a network connection.
More control: the model, prompts, generation logic, and validation can be inspected and improved instead of treating a remote API as a black box.
More accessibility to experimentation: developers can adapt open models and runtimes to build experiences that don't have to revolve around cloud infrastructure.

There are real trade-offs, of course. Model downloads take space, browser inference depends on device capabilities, and local models can produce imperfect results. Those constraints are part of the engineering challenge.

I chose this direction because an outdoor exploration companion should be able to work toward independence from the very connectivity that often keeps us indoors staring at screens.

My Agent Session

I used AI-assisted development to help build and debug the app, investigate local inference failures, improve mission validation, and establish the PWA foundation.

Agent session: [Add your DevRelay session link here, if available]

Prize Categories

I'll select the partner prize categories that match the tools and work actually demonstrated in the finished project. I won't claim a partner integration that isn't part of the implementation.

A small invitation

Next time you step outside, don't start by asking where to go.

Start by asking what you've stopped noticing.

LOST & FOUND — Disconnect to rediscover. 🌿

lost & found

Vanihba — Mon, 12 Oct 2026 04:47:14 +0000

LOST & FOUND — Disconnect to Rediscover 🌿

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

What I Built

What if AI didn't ask you to spend more time looking at a screen, but helped you discover a reason to put it down?

That's the idea behind LOST & FOUND — an offline-first outdoor exploration app designed to turn an ordinary walk into a small adventure.

LOST & FOUND is my attempt to change that.

Your mission might encourage you to:

Find something growing where it shouldn't be able to grow.
Notice a detail on your usual route that you've never paid attention to.
Discover a pattern in the architecture around you.
Find evidence of nature reclaiming a small piece of the city.
Record a tiny discovery that would normally go unnoticed.

The experience is built around one simple idea: you don't need to travel far to discover something new. Sometimes, you just need a different way of looking.

LOST & FOUND also includes a local journal for saving discoveries, an offline-first app shell, and a local AI engine integration designed to generate personalized missions on-device.

It's for curious people, students, solo walkers, and anyone who wants to reconnect with the physical world without turning outdoor exploration into another social media competition.

The goal isn't to collect screen time. It's to collect moments.

Demo

The app is currently being developed and tested locally.

Local development: http://localhost:5173/
Production preview: http://localhost:3000/

These are local addresses, not publicly accessible demo links. I'll add a deployed demo or a recorded walkthrough here when one is available.

Code

Project: LOST & FOUND

GitHub repository: [Add your public GitHub repository URL here]

The codebase is organized into separate pages, components, data, and services so that the interface, journal, and AI engine can evolve independently.

How I Built It

The stack

React + TypeScript — the app interface and core application logic.
Vite — development and production builds.
Tailwind CSS — the visual design system.
IndexedDB — local storage for journal entries.
Progressive Web App (PWA) — an installable app foundation with a service worker and cached application assets.
WebLLM — the browser-based local inference runtime being integrated for on-device mission generation.
Llama 3.2 1B Instruct — the open-weight model selected for the current WebLLM implementation, subject to successful runtime and device testing.

Building honestly for offline use

One important lesson from this project is that an offline interface and an offline AI are two different things.

The intended workflow is to download the required model assets while connected, initialize the local inference engine, and then test fresh mission generation with the network disabled.

I'm treating real offline inference as a capability that must be demonstrated on the target device—not something I can claim just because the app builds successfully.

Why Does Open Innovation Matter?

For this project, open innovation is about who controls the experience and where the intelligence runs.

An open-weight model and a local inference runtime offer a different direction:

More privacy: exploration preferences and personal reflections can remain on the device when the implementation is configured to use local processing.
Less dependence on connectivity: after the necessary assets are installed and local inference works, the experience can be designed to continue without a network connection.
More control: the model, prompts, generation logic, and validation can be inspected and improved instead of treating a remote API as a black box.
More accessibility to experimentation: developers can adapt open models and runtimes to build experiences that don't have to revolve around cloud infrastructure.

I chose this direction because an outdoor exploration companion should be able to work toward independence from the very connectivity that often keeps us indoors staring at screens.

My Agent Session

I used AI-assisted development to help build and debug the app, investigate local inference failures, improve mission validation, and establish the PWA foundation.

Agent session: [Add your DevRelay session link here, if available]

Prize Categories

I'll select the partner prize categories that match the tools and work actually demonstrated in the finished project. I won't claim a partner integration that isn't part of the implementation.

A small invitation

Next time you step outside, don't start by asking where to go.

Start by asking what you've stopped noticing.

LOST & FOUND — Disconnect to rediscover. 🌿>

The last manual

Vanihba — Sun, 04 Oct 2026 19:01:16 +0000

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

What I Built

The Last Manual

The Last Manual is an AI-powered visual troubleshooting assistant built for people who are stuck with a physical device, machine, appliance, or object and don't know how to fix it.

The idea came from a simple problem: when something breaks, people often don't know what the part is called, don't know which manual to search for, and don't know whether the next step they're about to take is safe.

Instead of forcing someone to search through complicated manuals or watch multiple videos, The Last Manual lets them take a picture of the problem.

The system analyzes the image using Gemma, identifies what it can see, reasons through the possible problem, and generates a structured troubleshooting manual with:

What was detected
What might be wrong
Safety warnings
Tools/materials that may be needed
Step-by-step instructions
When to stop and seek professional help

The instructions can then be converted into natural spoken guidance using ElevenLabs, so the user can keep their hands on the object instead of constantly looking at a screen.

I built it for the friend who always says:

"Bro... this thing isn't working. What do I do?"

The goal is to turn that moment from "I have no idea" into "Okay, let's fix this step by step."

Demo

Live Demo:

https://the-last-manual-frontend.onrender.com/

Backend API:

https://the-last-manual-backend.onrender.com/

GitHub:

https://github.com/vanihba0-lgtm/The-last-manual

Code

The complete source code is available on GitHub:

https://github.com/vanihba0-lgtm/The-last-manual

The project contains:

Next.js frontend
FastAPI backend
Gemma vision/troubleshooting pipeline
ElevenLabs voice output
Image capture/upload
Safety validation layer
Structured AI responses
Session-based troubleshooting flow

How I Built It

The core of The Last Manual is built around Gemma, an open-weight AI model.

Instead of using a closed vision API as the main reasoning engine, I built the troubleshooting pipeline around Gemma's ability to understand visual input and generate structured reasoning.

The basic flow is:

Camera → Image Capture → Gemma → Troubleshooting Analysis → Safety Validation → Manual → ElevenLabs Voice

The frontend is built with Next.js and the backend uses FastAPI/Python.

The backend sends the captured image to Gemma through an OpenAI-compatible interface and asks it to behave like a real troubleshooting expert rather than simply describing the image.

The response is structured into practical sections so that the user gets an actual manual rather than a generic chatbot response.

I also added a safety layer so potentially dangerous situations can be flagged before presenting instructions.

For accessibility and hands-free use, the generated instructions can be converted into spoken guidance using ElevenLabs.

Why Does Open Innovation Matter?

Open innovation matters because a troubleshooting assistant should not have to depend entirely on a black-box system that users cannot understand, modify, or control.

Using an open-weight model like Gemma gave me the ability to build the AI experience around the model instead of simply wrapping a closed chatbot API.

It also makes the project more adaptable.

The troubleshooting system can potentially be:

customized for specific types of equipment
fine-tuned for specialized domains
run in more private environments
adapted for offline or low-connectivity scenarios
inspected and improved by other developers

Most importantly, the open model is not just an extra feature in this project.

It is part of what makes The Last Manual possible.

I wanted to build something where AI isn't just answering questions — it is helping someone understand the physical world in front of them.

My Agent Session

Prize Categories

Build for a Friend
Open-source AI / Gemma

The last manual

Vanihba — Sun, 04 Oct 2026 18:50:24 +0000

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

What I Built

The Last Manual

The Last Manual is an AI-powered visual troubleshooting assistant built for people who are stuck with a physical device, machine, appliance, or object and don't know how to fix it.

Instead of forcing someone to search through complicated manuals or watch multiple videos, The Last Manual lets them take a picture of the problem.

The system analyzes the image using Gemma, identifies what it can see, reasons through the possible problem, and generates a structured troubleshooting manual with:

What was detected
What might be wrong
Safety warnings
Tools/materials that may be needed
Step-by-step instructions
When to stop and seek professional help

The instructions can then be converted into natural spoken guidance using ElevenLabs, so the user can keep their hands on the object instead of constantly looking at a screen.

I built it for the friend who always says:

"Bro... this thing isn't working. What do I do?"

The goal is to turn that moment from "I have no idea" into "Okay, let's fix this step by step."

Demo

Live Demo:

https://the-last-manual-frontend.onrender.com/

Backend API:

https://the-last-manual-backend.onrender.com/

GitHub:

https://github.com/vanihba0-lgtm/The-last-manual

Code

The complete source code is available on GitHub:

https://github.com/vanihba0-lgtm/The-last-manual

The project contains:

Next.js frontend
FastAPI backend
Gemma vision/troubleshooting pipeline
ElevenLabs voice output
Image capture/upload
Safety validation layer
Structured AI responses
Session-based troubleshooting flow

How I Built It

The core of The Last Manual is built around Gemma, an open-weight AI model.

Instead of using a closed vision API as the main reasoning engine, I built the troubleshooting pipeline around Gemma's ability to understand visual input and generate structured reasoning.

The basic flow is:

Camera → Image Capture → Gemma → Troubleshooting Analysis → Safety Validation → Manual → ElevenLabs Voice

The frontend is built with Next.js and the backend uses FastAPI/Python.

The backend sends the captured image to Gemma through an OpenAI-compatible interface and asks it to behave like a real troubleshooting expert rather than simply describing the image.

The response is structured into practical sections so that the user gets an actual manual rather than a generic chatbot response.

I also added a safety layer so potentially dangerous situations can be flagged before presenting instructions.

For accessibility and hands-free use, the generated instructions can be converted into spoken guidance using ElevenLabs.

Why Does Open Innovation Matter?

Open innovation matters because a troubleshooting assistant should not have to depend entirely on a black-box system that users cannot understand, modify, or control.

Using an open-weight model like Gemma gave me the ability to build the AI experience around the model instead of simply wrapping a closed chatbot API.

It also makes the project more adaptable.

The troubleshooting system can potentially be:

customized for specific types of equipment
fine-tuned for specialized domains
run in more private environments
adapted for offline or low-connectivity scenarios
inspected and improved by other developers

Most importantly, the open model is not just an extra feature in this project.

It is part of what makes The Last Manual possible.

I wanted to build something where AI isn't just answering questions — it is helping someone understand the physical world in front of them.

My Agent Session

Prize Categories

Build for a Friend
Open-source AI / Gemma