DEV Community: Zaid Kamil

Before We Scroll: An AI That Gets You Off the Screen and Into the Real World

Zaid Kamil — Mon, 12 Oct 2026 06:01:55 +0000

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

Before We Scroll: I Built an AI That Turns “Just 5 More Minutes” Into Something Real

There is a tiny moment that happens several times every day.

You have 5 minutes before a game starts.

15 minutes before you need to leave.

You are waiting for someone.

You are standing in a park with friends.

And almost automatically, the phone comes out.

Not because there is nothing else to do — but because figuring out what else to do right now takes more effort than opening another feed.

That was the problem I wanted to solve.

So I built Before We Scroll.

Less scrolling. More doing.

Before We Scroll takes whatever context you already have — text, voice, a photo of your surroundings, or a combination of them — and turns that moment into three short, practical real-world missions.

And after building it, I did the most important test:

I actually took it outside.

What I Built

Before We Scroll is a multimodal AI activity generator designed to turn idle screen time into real-world activity.

Instead of asking users to fill out a long form, they can simply:

type what is happening,
speak naturally,
take a photo of their surroundings,
or combine those inputs.

The application extracts a structured understanding of the situation, including things such as:

number of people,
available time,
activity goal,
desired intensity,
indoor or outdoor setting,
available space,
ground surface,
visible environmental features,
equipment,
and safety constraints.

Before generating anything, the user gets a Context Review screen where every interpreted detail can be checked and edited.

Then the system creates exactly three missions tailored to that context.

Each mission contains:

a title,
short description,
duration,
intensity,
player count,
equipment requirements,
an explanation of why it fits,
step-by-step instructions,
and safety guidance.

The user picks one, optionally listens to the mission using ElevenLabs text-to-speech, starts the mission timer, goes and does it, and comes back only when the activity is complete.

Afterward they can leave feedback and, optionally, share their experience with the public Real Outventures section.

The complete flow is:

Text / Voice / Photo

→ Context Understanding

→ Context Review

→ 3 Missions

→ Choose One

→ Listen

→ Start

→ Get Off the Screen

→ Complete

→ Reflect

→ Share

The important part is that the AI is not trying to keep the user chatting.

Its job is to understand the moment quickly enough that the next interaction happens away from the screen.

Demo

The build log contains the complete development journey, including model benchmarks, multimodal testing, timer architecture, voice integration, MongoDB persistence, GridFS storage, and the final product redesign.

I Took It Outside

Building an application for the Touch Grass challenge without actually taking it outside felt wrong.

So instead of stopping once the app deployed successfully, I created five different real-world test cases.

I intentionally varied the input method and the kind of reasoning required.

The five tests covered:

Photo + Text — visual context and indirect time reasoning
Photo + Voice — combining spoken details with visual surroundings
Photo + Text — environment-aware exploration
Text Only — complex constraint following
Voice Only — conversational speech understanding

I also completed missions and added real feedback rather than only checking whether the API returned JSON.

Test 1 — Five Minutes Before Futsal

This became one of my favorite tests.

I uploaded a real photo taken inside an indoor futsal arena.

The photo showed the venue and several people, but I deliberately did not tell the AI:

how many people were there,
whether we were indoors,
what the surface was,
how large the space was,
what features surrounded us,
or what equipment was available.

The only text I gave it was:

“We have five minutes left before our game starts. Tell us something active we can do while we wait.”

Notice that I did not explicitly say:

“Create a five-minute mission.”

The system had to understand that five minutes left before the game means roughly five minutes of usable activity time.

What it understood

The Context Review identified:

4 people
5 available minutes
activity goal: active waiting before a game
indoors
large space
artificial turf
indoor sports arena
safety netting
overhead lighting
metal frame structure

It also correctly avoided adding equipment that was not clearly available.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/q0hf2nktwrkcce2dhzbk.jpeg)

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/j6xsl2odlglglmvqqk4d.png)

That was exactly the sort of multimodal behavior I wanted from the project.

The image supplied the physical world.

The sentence supplied the intent and time constraint.

The AI joined the two.

Missions generated

It produced three five-minute ideas:

Netting Geometry Challenge
Arena Soundscape Mapping
Lighting Shadow Play

I selected Lighting Shadow Play, which used the arena's overhead lighting and turf to create a quick movement activity.

What impressed me most was that this was not a generic “do jumping jacks for five minutes” answer.

It was built from features that were actually visible in the environment.

My feedback afterward was:

“The mission matched our space really well and gave us a fun, active way to use the few minutes we had before the game.”

Test 2 — A Backyard, Two Rackets, Seven Minutes

For the second test I changed the input method.

I uploaded a photo of a grassy residential yard and used voice input instead of typing.

I spoke naturally:

“My friend and I have about seven minutes to kill before we head out. We’ve got two rackets and a shuttlecock with us — give us something quick and fun to do in this space.”

This test divided the information between two sources.

The voice provided:

two people,
roughly seven minutes,
two rackets,
a shuttlecock,
and the desire for something quick and fun.

The photo provided:

the outdoor setting,
grassy surface,
available space,
walls,
trees,
gate,
and surrounding features.

The goal was to see whether the system would combine both sources rather than treating them separately.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/g211oyw3ozywuy870npb.jpeg)

Missions generated

One of the suggestions was:

The Gate-to-Tree Rally

It transformed a normal badminton rally into a small precision challenge using boundaries already present in the yard.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/32xllzonoecele57cdnk.png)

I already had a real image showing the activity happening in the same space, which made this one especially satisfying to test.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/8wcck8c6phnnf319o80a.png)

My feedback:

“The mission matched the space well and made good use of the rackets and shuttlecock we already had. It turned a simple rally into a quick, fun challenge.”

Test 3 — Turning a Park Into an Exploration Mission

The third test happened in a much larger outdoor environment.

The image showed an open grassy historic area with paths, trees and surrounding landmarks.

This time I supplied:

“I’m here with two kids and we’ve got a football with us. We have about 15 minutes before we need to leave, and we want to do something fun that gets us moving around and exploring this place.”

Here I wanted to see whether the system would avoid generating just another football drill.

The word “exploring” mattered.

The physical environment mattered.

And the activity needed to remain suitable for a mixed group.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/dyesa0cvd9jcax369umz.jpeg)

Missions generated

The three generated ideas included:

Cannonball Guardian
The Historic Path Finder
Pass the History

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/icfaldapmc89h2jm0877.png)

I chose:

The Historic Path Finder

Instead of simply passing the football back and forth, the mission encouraged us to move through the location and use the ball as part of an exploration challenge.

That was a great example of the AI using the character of the location, rather than treating every grassy area as the same place.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/3vha6ok3fl15h9jiyqnt.jpeg)

My feedback:

“This mission fit the location really well and made the walk feel more engaging. Using the football while exploring different points around the fort made the activity simple, fun, and easy to follow.”

Test 4 — No Image, Just Constraints

For Test 4 I removed vision entirely.

The input was only text:

“Four of us are stuck inside for about 12 minutes while we wait for dinner. We want something competitive and energetic, but the room isn’t very big, we can’t run, and we don’t have any equipment.”

This was deliberately designed to contain several interacting constraints:

four people,
12 minutes,
indoors,
limited space,
competitive,
energetic,
no running,
no equipment.

Some of those requirements even pull in opposite directions.

“Energetic” normally encourages movement.

“No running” restricts it.

“Competitive” often introduces equipment.

“No equipment” removes that option.

So this test was less about vision and more about whether the mission generator could respect all of the constraints simultaneously.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/mdq24rg71mjxvyh1xbdo.jpeg)

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/0yz5rn9k2pbjnolkil55.jpeg)

The generated activities stayed within the available space and did not suddenly invent balls, cones, cards, or other equipment.

My feedback:

“The missions followed the constraints really well. They stayed competitive and active without requiring running, extra space, or any equipment.”

Test 5 — Talking Like a Normal Person

The last test was voice only.

No image.

No carefully structured sentence.

I intentionally spoke more like someone would actually speak:

“Okay, so it’s just me and my friend right now. We’ve probably got maybe twenty minutes before we need to head off. We’re both pretty tired, so nothing too intense, but we also don’t want to just sit around. We don’t have anything with us either. Give us something chill but still fun.”

This test actually exercises two AI stages.

First:

ElevenLabs Speech-to-Text

has to correctly transcribe casual speech, including words such as:

“okay”
“probably”
“maybe”
“pretty tired”

Then the language model has to find the useful meaning inside that transcript.

The important context is:

two people,
around 20 minutes,
low intensity,
no equipment,
something fun,
environment unspecified.

A good system should also know what not to infer.

Because I never supplied a photo or location, it should not confidently invent a park, beach, garden or indoor court.

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/xm5fo8r4x1fr2z7fzlux.jpeg)

(https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/43hqytmn0c5peuc6rznx.jpeg)

My feedback:

“The app understood the casual voice input surprisingly well and suggested activities that matched our limited energy, time, and lack of equipment.”

What I Learned From Testing It Outside

The most useful lesson was that multimodal AI becomes much more interesting when each input carries a different part of the truth.

In the futsal test:

Image
→ people + arena + turf + environmental features

Text
→ only five minutes left + desire to stay active

In the backyard test:

Image
→ garden + grass + physical boundaries

Voice
→ two people + seven minutes + rackets + shuttlecock

The model's job is not simply to “look at a photo.”

It has to merge different pieces of context into one useful representation.

Another important result was what happened when information was missing.

Before We Scroll's context schema intentionally supports unknown values.

If the system does not know something, I prefer:

null

over a confident hallucination.

The Context Review exists specifically because AI interpretation should remain transparent and correctable.

Code

The entire project is available here:

sheda3838 / before-we-scroll

Before We Scroll

Less scrolling. More doing.

Before We Scroll turns text, voice, and photos of your surroundings into tailored real-world missions designed to get you away from the screen and into the moment

Explore the Live Demo →

Quick Links

Live Production App: https://before-we-scroll.vercel.app/
GitHub Repository: https://github.com/sheda3838/before-we-scroll
Detailed Build Log: BUILD_LOG.md

Project Overview

The Problem

When people have 15 or 30 minutes of free time, they default to scrolling feeds on autopilot. Even when standing in a park, sitting on a balcony, or hanging out in a living room, the phone screen wins by default—not because physical surroundings lack interesting things to do, but because deciding what to do takes effort.

The Solution

Before We Scroll acts as a catalyst between screen fatigue and real-world engagement. By taking in what you have around you—through typed intent, spoken thoughts, or a quick snapshot of your environment—it extracts a structured understanding…

View on GitHub

Or directly:

👉 github.com/sheda3838/before-we-scroll

The repository also contains a detailed engineering journal:

👉 BUILD_LOG.md

How I Built It

Before We Scroll is a full-stack Next.js 16 App Router application written in TypeScript.

Frontend

Next.js 16
React 19
TypeScript
Tailwind CSS 4
Lucide React
responsive mobile-first interface
light and dark themes

AI

Google GenAI SDK
Gemini 3.1 Flash Lite
Gemma 4 models used during model evaluation and benchmarking
ElevenLabs Speech-to-Text
ElevenLabs Text-to-Speech

Persistence

MongoDB
MongoDB GridFS for optional completion photos

Deployment

Vercel

The production app is:

👉 before-we-scroll.vercel.app

The AI Pipeline

The project uses AI at several distinct stages instead of making one giant prompt do everything.

1. Context Extraction

POST /api/context/analyze

Text and/or image input is converted into a structured MissionContext.

The structure includes:

people count
duration
activity goal
intensity
age group
environment type
indoor/outdoor
space size
surface
visible features
obstacles
available equipment
constraints

The user can review and edit everything before proceeding.

2. Mission Generation

POST /api/mission/generate

The confirmed context becomes the source of truth.

A single AI request returns exactly three complete mission objects.

Each contains:

title
description
duration
intensity
players
required equipment
why it fits
steps
safety notes

No second AI call is necessary when a user selects a mission.

3. Voice Input

POST /api/transcribe

The browser records audio using MediaRecorder.

The temporary audio blob is sent server-side to ElevenLabs Speech-to-Text.

The transcript is placed back into the normal input flow.

Audio is not permanently stored.

4. Mission Narration

POST /api/tts

ElevenLabs Text-to-Speech generates mission narration.

Before the mission starts, users can listen to the complete briefing.

During the active mission, the app can read only the actionable steps and safety information.

Audio is cached temporarily in the browser so replaying does not repeatedly call the API.

5. The Timer

One thing I deliberately avoided was a timer based only on decrementing React state.

Instead the mission stores:

startedAt
expectedEndAt

Remaining time is calculated from the current timestamp.

That means:

refreshing the page does not reset the mission,
switching tabs does not desynchronize it,
and background browser throttling does not destroy the countdown.

6. Feedback and Real Outventures

After completion, users can submit:

a 1–5 rating,
whether the activity matched their context,
instruction accuracy,
difficulty,
an optional comment,
and an optional completion photo.

Completion records are persisted to MongoDB.

Images are stored using GridFS, rather than being embedded as huge base64 strings inside normal documents.

Public sharing is controlled separately for feedback and photos.

The public endpoint exposes only a sanitized DTO containing the fields needed by the Real Outventures feed.

Session IDs, private context and other internal information are not returned.

Why I Benchmarked the Models

I originally expected to use Gemma much more heavily throughout the application.

Instead of choosing a model based on reputation alone, I benchmarked it.

For context extraction I tested:

Gemma 4 26B A4B

average latency: approximately 30.35 seconds
median: approximately 28.77 seconds
strong structured extraction quality

Gemma 4 31B

average latency: approximately 71.06 seconds
median: approximately 71.52 seconds
no meaningful accuracy improvement over the smaller variant

Gemini 3.1 Flash Lite

average latency: approximately 2.88 seconds
median: approximately 1.12 seconds
100% successful responses in the controlled test
strong schema adherence

I also separately benchmarked mission-generation quality.

The final production path uses Gemini 3.1 Flash Lite for the interactive context and mission-generation workflows because the latency difference dramatically changed the usability of the product.

Gemma remained extremely valuable during development because it gave me an open-weight reference point against which I could evaluate speed, structured output quality and creative mission generation.

The detailed benchmark methodology is available in the build log:

👉 Model benchmarking and architecture decisions

Why Does Open Innovation Matter?

This project changed significantly because I could experiment rather than treating one model as a black box that simply had to be accepted.

Working with open-weight models such as Gemma gave me a meaningful architectural baseline.

I could ask:

How much quality do I actually gain from a larger model?
Is the latency appropriate for an interactive product?
Which stages truly need creative reasoning?
Which stages are primarily structured extraction?
Could the mission layer eventually be self-hosted or swapped without redesigning the complete application?

The answer was not “one model should do everything.”

The architecture became better because models could be evaluated as components.

The same principle applies to the rest of the project.

MongoDB gives me control over the application's data model.

GridFS gives me direct binary persistence without tying the MVP to another storage provider.

The application code itself is publicly available so the architecture, experiments and trade-offs can be inspected rather than hidden behind a demo.

To me, that is the useful part of open innovation:

being able to understand, compare, replace and improve the pieces instead of treating the technology as magic.

Prize Categories

The project uses:

ElevenLabs — Speech-to-Text input and Text-to-Speech mission narration
MongoDB / GridFS — completion persistence and optional photo storage
Google AI / Gemma — open-weight model evaluation and benchmarking during development

Final Result

Before We Scroll started with a very simple question:

What if the moment before another scroll could become the moment you actually did something?

Now the application can:

listen to you,

look at your surroundings,

understand your constraints,

create something realistic to do,

read the instructions aloud,

start a timer,

and then get out of your way.

The most rewarding part of this challenge was not seeing the build pass.

It was taking the application outside and seeing AI suggestions turn into actual movement, games, exploration and time spent with other people.

That feels much closer to what I want AI to do:

not always give us another reason to stay on a screen, but sometimes give us a good reason to leave it.

Try Before We Scroll

🌐 Live: https://before-we-scroll.vercel.app/

💻 Code: https://github.com/sheda3838/before-we-scroll

📖 Build Log: BUILD_LOG.md

Echo Shelf 2.0: Turning Saved Knowledge Into a Living Second Brain

Zaid Kamil — Mon, 05 Oct 2026 06:25:10 +0000

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

What I Built

We save useful knowledge every day.

An interesting article gets bookmarked. A useful YouTube video gets added to a playlist. A GitHub repository gets starred. A PDF gets downloaded. An idea gets written into a note.

And then, most of it disappears into the digital pile.

I built Echo Shelf 2.0, an intelligent personal knowledge vault, for a friend who, like many of us, constantly saves useful articles, YouTube videos, GitHub repositories, documents, images, and notes—but rarely gets meaningful value from them again.

The problem wasn't saving information.

The real problem was finding it again, understanding how different saved resources connect, and remembering it when it becomes relevant.

That became the foundation of Echo Shelf 2.0:

Capture → Connect → Resurface

Instead of building another bookmark manager, I wanted to create a living second brain that understands what you save, discovers relationships between your knowledge, and brings old information back when it becomes useful again.

Capture

Save knowledge from different sources and let Echo Shelf understand what was actually saved.

Connect

Discover meaningful relationships between resources that may have been saved days or weeks apart.

Resurface

Bring old knowledge back when something happening now makes it relevant again.

Imagine saving an article about a technology, business strategy, research topic, or idea today.

Weeks later, something related happens in the world.

Instead of expecting you to remember that old bookmark, Echo Shelf can make that connection for you.

What Can Echo Shelf Save?

Echo Shelf supports eight content types:

📰 Articles
🎥 YouTube videos
💻 GitHub/GitLab repositories
🔗 Generic URLs
🖼️ Images
📄 Documents
📝 Notes
🧩 Multi-source "Other" entries

A multi-source entry can combine things such as a personal note, several reference URLs, documents, and images into a single knowledge asset.

But I didn't want the AI to blindly guess what a URL or document contained.

That led to one of the most important architectural decisions in the project.

Smart Capture: Ground the AI Before Asking It to Think

A simple implementation could have looked like this:

URL → AI → "Tell me what this is"

I deliberately avoided that.

Instead, Echo Shelf follows a source-grounded pipeline:

User Input
    ↓
Source-Specific Extraction
    ↓
Normalized Context
    ↓
Gemma
    ↓
Structured Metadata
    ↓
User Review
    ↓
Persistence

The key principle is:

Extraction first. AI reasoning second.

Different sources therefore have different extraction paths.

🌐 Articles and Web Pages

Web pages are fetched server-side and processed using Mozilla Readability + JSDOM.

This extracts the meaningful readable content while removing much of the surrounding navigation, advertising, and page clutter.

🎥 YouTube Videos

YouTube URLs are resolved using the YouTube Data API v3.

Echo Shelf can retrieve grounded metadata such as:

Title
Description
Channel
Publication information
Duration
Thumbnail

Gemma therefore reasons over actual video metadata rather than trying to infer the contents from a URL.

💻 GitHub and GitLab Repositories

Repository URLs are processed using the relevant repository APIs.

Echo Shelf gathers repository metadata and README content before passing normalized context to Gemma.

📄 Documents

PDF and supported Office documents are parsed into textual context before AI processing.

The extracted information is normalized and treated as untrusted source content.

🖼️ Images

Images are handled using Gemma's multimodal capabilities.

This allows visual knowledge such as screenshots, diagrams, charts, and infographics to become part of the user's knowledge library.

📝 Notes

Notes already contain user-provided source content, so they can move directly into the normalization and intelligence pipeline.

The result is that Gemma receives grounded information rather than being expected to invent the contents of an inaccessible resource.

Gemma Is the Intelligence Layer

Echo Shelf 2.0 uses:

Gemma 4 26B — gemma-4-26b-a4b-it

through Google's Gemini Developer API.

I didn't want Gemma to exist as a chatbot sitting beside the application.

Instead, I wanted the model to become part of the application's reasoning architecture.

Gemma powers four major intelligence layers:

Smart Capture
      ↓
Smart Connections
      ↓
Knowledge Clusters
      ↓
Contextual Rediscovery

Each layer builds on the previous one.

✨ Smart Capture

After Echo Shelf extracts a source, Gemma analyzes the normalized context and generates useful structured information such as:

Title
Description
Tags
Relevant metadata

The generated information is not blindly persisted.

The user can review and edit the generated metadata before saving the item.

I also deliberately kept duplicate detection outside the AI layer.

Echo Shelf uses deterministic mechanisms such as:

Canonical URL normalization
SHA-256 content fingerprints

This creates an important separation:

AI handles semantic understanding. Deterministic software handles exact identity.

🔎 Potential Connections

Even before an item is saved, Echo Shelf can look for possible relationships with existing knowledge.

However, I didn't want every operation to require an expensive AI call.

So Potential Connections are deterministic.

Echo Shelf compares information such as:

Tags
Titles
Keywords
Descriptions

to cheaply shortlist potentially related resources.

This provides immediate feedback while reserving Gemma for the deeper semantic reasoning that actually benefits from AI.

🔗 Smart Connections

After an item has been saved, the user can run Check Connections.

This is where Gemma performs deeper semantic reasoning.

The process has two stages.

Stage 1 — Deterministic Candidate Selection

Echo Shelf searches the authenticated user's library and creates a small shortlist of promising candidates.

Stage 2 — Gemma Semantic Analysis

Only those candidates are passed to Gemma for semantic analysis.

Gemma can classify relationships such as:

prerequisite
extends
complementary
conceptual-overlap
practical-application
contrast
alternative-approach
implementation-detail

The relationship also includes a strength and an explanation.

The result is that the user's library gradually becomes an interconnected knowledge graph rather than a flat collection of bookmarks.

Gemma can also reject candidates when apparent keyword similarity does not represent a meaningful conceptual relationship.

🧠 Knowledge Clusters

Individual connections are useful, but I wanted Echo Shelf to answer a bigger question:

What larger subjects am I actually building knowledge around?

That's where Knowledge Clusters come in.

Echo Shelf creates lightweight representations of the user's saved items using information such as:

Item ID
Title
Description
Tags
Content type

Gemma then looks for meaningful conceptual groups.

A generated cluster can contain:

A thematic title
A summary
Related saved items
Semantic tags

The system intentionally avoids forcing every item into a cluster.

If something doesn't meaningfully belong anywhere, it can remain ungrouped.

This prevents the feature from becoming a simple AI-generated folder system.

Instead, the goal is to identify real conceptual patterns across the user's knowledge.

🛠️ When AI Reasoning Took Longer Than Expected

Knowledge Clusters also created one of the most interesting engineering problems during development.

During testing, cluster generation appeared to simply stop working.

The request would run for a long time and eventually fail.

After investigating the actual model response behavior, I found that Gemma could spend a significant portion of the generation budget on internal reasoning before producing the final structured response.

Earlier output limits could therefore terminate generation before the useful JSON was returned.

I had to account for:

Thought-token separation
Structured JSON responses
Output limits
Longer inference times
Serverless execution limits
Validation of generated IDs

Another production blocker appeared because complex clustering operations could take roughly 45–55 seconds.

The final solution included:

Increasing the Gemma timeout
Using structured JSON response mode
Limiting the candidate set
Trimming descriptions before inference
Allowing longer execution for the clustering route
Validating generated item IDs before persistence

After the changes, Knowledge Cluster generation successfully completed during browser testing.

This was an important lesson from the project:

Integrating AI isn't just about getting a successful model response. You also have to engineer around reasoning time, token budgets, latency, structured output, failure recovery, and the execution environment around the model.

🌍 Contextual Rediscovery

This became my favorite part of Echo Shelf.

Saving and organizing information is useful.

But I wanted Echo Shelf to do something more proactive:

Tell me when something I already know becomes relevant again.

Contextual Rediscovery starts with the user's Knowledge Clusters.

Knowledge Clusters
        ↓
High-Signal Topics
        ↓
GNews
        ↓
Current Articles
        ↓
Gemma Relevance Analysis
        ↓
Old Knowledge Resurfaced

Echo Shelf derives compact topics from the user's clusters and queries GNews for current developments.

Gemma then compares those developments against the user's existing knowledge.

The central question becomes:

What is happening now that makes something I saved before relevant again?

Only meaningful matches are surfaced.

A Rediscovery result can connect:

📰 A current article
📚 Previously saved knowledge
🧠 A relevant Knowledge Cluster
💡 An explanation of why the connection matters

This completes the original idea:

Capture → Connect → Resurface

The shelf isn't just storing information anymore.

It is helping decide when that information matters again.

🐛 Debugging Rediscovery

Rediscovery produced another interesting real-world problem.

The GNews API key was valid and direct requests worked, but running Rediscovery across multiple topics sometimes resulted in failures.

The problem turned out to be rate limiting.

Multiple searches were being sent too quickly, causing HTTP 429 responses.

Some generated search queries were also too specific and returned little useful information.

I changed the system to:

Pace GNews requests
Prefer shorter, high-signal thematic queries
Apply explicit request timeouts
Handle provider errors more precisely
Preserve previous valid Rediscovery results when a refresh fails

After those changes, Echo Shelf successfully retrieved current news and connected it to previously saved knowledge.

That was the point where the Resurface part of the project really came alive.

🔐 Security Was Part of the Architecture

Echo Shelf processes arbitrary URLs, documents, AI-generated output, and private user knowledge.

Because of that, security couldn't simply be added at the end.

Server-Verified Identity

Authentication is handled using Supabase Auth.

Every protected server operation derives the user's identity from the verified session.

The application does not trust an arbitrary userId supplied by the browser.

MongoDB Tenant Isolation

Every user-owned MongoDB record is associated with a user.

Reads, updates, deletes, AI candidate selection, connections, clusters, and rediscovery operations are scoped to the authenticated owner.

Cross-user resources are treated as unavailable rather than revealing whether another user's record exists.

SSRF Protection

Fetching arbitrary URLs server-side introduces Server-Side Request Forgery (SSRF) risk.

The extraction layer therefore protects against unsafe targets including:

Private network ranges
Loopback addresses
Link-local and metadata endpoints
Unsafe protocols
Redirects toward internal addresses
Unsafe DNS resolutions

Prompt Injection Boundaries

Extracted webpages and documents are treated as untrusted data.

Their contents are separated from model instructions so text such as:

Ignore all previous instructions...

is treated as part of the source material rather than a trusted instruction.

AI Output Validation

AI-generated output is also treated as untrusted.

Generated IDs, relationships, strengths, and other structured values are validated before they can affect persisted application data.

For me, this became another important principle:

Model output is another trust boundary.

Demo

🚀 Live Application:

https://echo-shelf-2.vercel.app/

The deployed application supports the complete workflow:

Authentication
      ↓
Smart Capture
      ↓
Personal Library
      ↓
Smart Connections
      ↓
Knowledge Clusters
      ↓
Contextual Rediscovery

Code

💻 GitHub Repository:

https://github.com/sheda3838/echo-shelf-2

The repository contains:

Complete application source
Architecture documentation
Automated tests
Security tests
Project README
Detailed BUILD_LOG.md

The build log documents not only what worked, but also the architectural decisions, bugs, failed approaches, security hardening, production blockers, and fixes encountered throughout development.

⚙️ Tech Stack

Layer	Technology
Framework	Next.js 16
Frontend	React 19 + TypeScript + Tailwind CSS
AI	Gemma 4 26B (`gemma-4-26b-a4b-it`)
AI Access	Google Gemini Developer API
Database	MongoDB Atlas + Mongoose
Authentication	Supabase Auth
Current News	GNews API
Video Metadata	YouTube Data API v3
Web Extraction	Mozilla Readability + JSDOM
Deployment	Vercel

🧪 Testing It

I built automated tests around the areas where failures would matter most, including:

Authentication
User isolation
Duplicate detection
Smart Capture
Smart Connections
Knowledge Clusters
Contextual Rediscovery
Security boundaries
Document processing
Image processing

Before deployment, the project also passed its core quality gates:

TypeScript        → PASS
ESLint            → PASS
Production Build  → PASS
Smart Connections → PASS
Knowledge Clusters → PASS
Rediscovery       → PASS

I also performed browser testing of the actual intelligence workflow rather than relying entirely on mocked responses.

How I Built It

Echo Shelf 2.0 was built as a fresh project for the Hacktoberfest Weekend Challenge.

The development process was iterative:

Idea
 ↓
Secure Application Foundation
 ↓
Authentication + User Isolation
 ↓
Source Extraction
 ↓
Smart Capture
 ↓
Duplicate Prevention
 ↓
Potential Connections
 ↓
Smart Connections
 ↓
Knowledge Clusters
 ↓
Contextual Rediscovery
 ↓
Adversarial + Security Testing
 ↓
UI/UX Refinement
 ↓
Production Debugging
 ↓
Deployment

One principle stayed consistent throughout the project:

Use deterministic software when the answer should be deterministic. Use Gemma when semantic reasoning genuinely adds value.

That means things such as:

Authentication
Authorization
Duplicate detection
Tenant isolation
Candidate filtering
URL security
Persistence
Validation

remain conventional deterministic software.

Gemma handles the parts that genuinely benefit from semantic intelligence.

That separation made Echo Shelf much easier to reason about, test, secure, and debug.

Why Does Open Innovation Matter?

The most interesting part of building Echo Shelf wasn't simply adding an AI API.

It was designing a system around an open-weight model.

Gemma isn't a decorative chatbot bolted onto the side of Echo Shelf.

It is responsible for the semantic intelligence connecting the product:

Capture → Semantic Connections → Knowledge Organization → Contextual Rediscovery

An open model ecosystem makes it possible to think beyond a single opaque endpoint.

The intelligence layer can evolve with:

Different model versions
Different inference environments
Deployment strategies
Performance optimizations
Community improvements

while the deterministic architecture surrounding it can remain stable.

Open innovation also encouraged me to think carefully about what AI shouldn't do.

I didn't use Gemma for authentication.

I didn't use it to determine whether two URLs are identical.

I didn't let it decide whether a user owns a database record.

I didn't let generated IDs enter the database without validation.

Instead:

Deterministic Engineering
          +
Open-Weight Intelligence
          =
A More Reliable AI-Native Product

For me, that's what makes open AI exciting.

The model becomes something developers can build around, experiment with, optimize, and learn from—not simply a black box behind a chat interface.

My Agent Session

I used DevRelay during the Hacktoberfest development workflow while building Echo Shelf 2.0.

My development process included:

Architecture design
Implementation
AI integration
Adversarial QA
Security hardening
Browser verification
Production debugging
Deployment preparation

The full engineering journey is also documented publicly in the repository's build log:

👉 View the Echo Shelf 2.0 BUILD_LOG

Prize Categories

🟢 Best Use of Gemma

I'm entering Best Use of Gemma because Gemma is the central semantic intelligence layer of Echo Shelf 2.0.

Gemma powers:

✨ Smart Capture
🖼️ Multimodal image understanding
🔗 Smart Connections
🧠 Knowledge Clusters
🌍 Contextual Rediscovery

The application is deliberately designed around Gemma's semantic reasoning capabilities rather than using the model as a standalone chatbot.

Without that reasoning layer, Echo Shelf would largely be another storage application.

Gemma is what turns the shelf into an intelligent knowledge system.

🍃 Best Use of MongoDB Atlas

I'm also entering Best Use of MongoDB Atlas.

MongoDB Atlas serves as Echo Shelf's production persistence layer for the user's knowledge system, including saved assets and the structures built around them.

The document model fits naturally with the different shapes of:

Articles
Videos
Repositories
Documents
Notes
Metadata
Connections
Knowledge Clusters
Rediscovery results

Every user-owned record is tenant-scoped, and ownership is derived from server-verified authentication.

This lets MongoDB Atlas act as the persistent foundation beneath Echo Shelf's AI intelligence layer.

Final Thoughts

Echo Shelf 2.0 started with a simple frustration:

We save far more knowledge than we ever use again.

I didn't want to solve that by creating another folder system.

I wanted the saved knowledge itself to become more useful.

Something that understands what you captured.

Something that notices when two ideas connect.

Something that recognizes the larger themes you're learning about.

And most importantly:

Something that knows when an old piece of knowledge matters again.

That's Echo Shelf 2.0.

Capture it. Connect it. Resurface it.

🚀 Live Demo:

https://echo-shelf-2.vercel.app/

💻 Source Code:

https://github.com/sheda3838/echo-shelf-2

Built for the Hacktoberfest 2026 Weekend Challenge: Build for a Friend.

Echo Shelf: An AI Knowledge Lake That Connects What You Save to What Matters Now

Zaid Kamil — Sun, 04 Oct 2026 22:30:38 +0000

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

What I Built

I built Echo Shelf, an AI-assisted personal knowledge lake designed around one problem I kept running into:

I save useful articles, videos, repositories, screenshots, documents, and notes — but most of them disappear into a bookmarking graveyard and I rarely return to them.

Echo Shelf turns that passive collection into an active knowledge system.

The core idea is:

Capture → Connect → Resurface

Instead of only storing links, Echo Shelf:

captures knowledge from multiple source types
extracts useful context from each source
generates structured metadata with AI
finds meaningful relationships between saved items
groups related knowledge into thematic clusters
connects current news back to things I saved before

The application supports eight content types:

Articles
Videos
Repositories
URLs
Images
Documents
Notes
Other resources

Smart Capture

Smart Capture analyzes the actual source before generating metadata.

Different sources use different extraction pipelines:

Articles and URLs → Mozilla Readability + jsdom
GitHub/GitLab repositories → provider APIs + README content
YouTube videos → YouTube Data API metadata
PDF/DOCX/PPTX/XLSX documents → format-specific parsers
Images → Groq Vision using qwen/qwen3.8-27b
Notes → direct text context

The extracted context is then sent through Groq for editable:

title
description
tags

The user can always review and edit the AI output before saving.

Smart Connections

After an item is saved, Echo Shelf can discover relationships between it and existing knowledge.

I intentionally split this into two stages.

First, a deterministic metadata shortlist compares:

tags
title keywords
description keywords

Only the strongest candidates are sent to the LLM.

Then openai/gpt-oss-120b evaluates whether the relationship is genuinely useful and returns:

relationship type
strength
explanation

This also means the AI is allowed to reject superficial keyword matches instead of forcing a connection.

Knowledge Clusters

Echo Shelf can analyze lightweight metadata across the user's library and discover broader themes.

For the final demonstration library, it successfully discovered themes such as:

Retrieval-Augmented Generation & Vector Search
Next.js Server Actions
Docker & Kubernetes Networking
Developer Productivity & Deep Work
Ergonomics & Workplace Health
Sleep Hygiene & Recovery

An item can belong to more than one cluster when that relationship is genuinely useful.

Contextual Rediscovery

This is the feature that completes the original idea.

Echo Shelf asks:

What is happening now that makes something I saved before relevant again?

Knowledge Cluster metadata is converted into compact news queries and sent to the GNews API.

Recent articles are then compared against saved knowledge using Groq.

Only meaningful strong or moderate matches are retained.

Each result explains:

Why this matters to your shelf

and links the current news article back to the related saved item and Knowledge Cluster.

Other details

Echo Shelf also includes:

exact duplicate detection using canonical URLs and SHA-256 fingerprints
email/password authentication
Google OAuth
GitHub OAuth
SSR cookie sessions with Supabase
server-enforced per-user ownership
embedded Sanity Studio
responsive branded UI
loading and pending states for asynchronous actions
duplicate-click prevention

The final application is a custom Next.js interface built on top of the Sanity Content Lake rather than a traditional CMS frontend.

Demo

Live Application

👉 https://echo-shelf-three.vercel.app/

Demo Account

The account below is pre-populated with a multi-domain knowledge library so the full experience can be explored immediately.

Email: echoshelf@gmail.com

Password: password

Recommended Testing Flow

Sign in using the demo account.
Browse the Library and its mixed content types.
Open saved items and inspect their Smart Connections.
Open Clusters to explore AI-discovered knowledge themes.
Open Rediscover to see current developments connected back to saved knowledge.
Try Add Item to test Smart Capture yourself.

Screenshots

Library / Personal Knowledge Lake

Smart Capture

Knowledge Clusters

Contextual Rediscovery

Authentication

Code

Source code:

👉 https://github.com/sheda3838/echo-shelf

The repository also contains:

👉 BUILD_LOG.md

I kept the build log throughout development instead of reconstructing the process at the end.

It records the decisions, failed approaches, manual tests, architectural changes, debugging sessions, and production fixes that shaped the final application.

My Build Process

I built Echo Shelf using an AI-native development workflow with Antigravity IDE, but I did not treat generated code as automatically correct.

My workflow was generally:

define a small milestone → prompt the IDE → inspect the implementation → run automated checks → manually test real flows → document what failed → refine

The most useful prompts were the ones with very narrow constraints.

Instead of asking:

"Build an AI knowledge app"

I broke Echo Shelf into individual systems such as:

define the Sanity schema
create the dynamic Add Item flow
implement one source extractor at a time
build deterministic candidate shortlisting
add AI relationship validation
introduce first-class Knowledge Cluster documents
build Rediscovery around persisted cluster metadata
introduce authenticated per-user ownership
harden production behavior

Where the model got things wrong

There were several cases where the first generated approach worked in theory but failed against real usage.

1. OCR was the wrong approach for general images

My first Image Smart Capture implementation used Tesseract.js OCR.

It worked for screenshots containing lots of text.

Then I tested it with a normal photo.

The OCR produced meaningless fragments, and the text model generated metadata about the OCR noise instead of describing the image.

That changed the architecture completely.

I replaced:

Image → OCR → text model

with:

Image → Groq Vision → structured metadata

using qwen/qwen3.8-27b.

That immediately made photos, diagrams, screenshots, and mixed visual content much more useful.

2. Document extraction passed tests but broke in the real browser flow

The document parser initially looked correct in automated testing.

Manual testing exposed several framework-level issues:

pdf-parse package entry behavior during Next.js bundling
Server Action body limits for uploaded files
extraction failures being incorrectly reported as AI failures

Those were fixed individually instead of hiding them behind a generic error.

This was one of the biggest reminders during the project that passing static checks is not the same as testing an actual product flow.

3. Production Smart Capture failed after deployment

After deploying to Vercel, Article Smart Capture suddenly returned HTTP 500 even though the local production build succeeded.

Vercel logs revealed an ESM/CommonJS incompatibility inside the deployed jsdom dependency chain.

The failure happened before the requested article was even fetched.

Instead of rewriting Smart Capture, I traced the runtime dependency problem and pinned jsdom to a compatible version while keeping the Readability architecture unchanged.

4. Knowledge Clusters became unstable with realistic demo data

The small test library worked.

The final demonstration library contained 41 saved items, and suddenly cluster generation became inconsistent:

sometimes 4 clusters
sometimes 2
sometimes a generic error

I built a non-persisting diagnostic runner and repeated the same generation multiple times.

The actual problem was not Sanity or cluster validation.

openai/gpt-oss-120b was spending too much of its completion budget on reasoning, causing Groq's JSON output to be truncated before it could form a valid document.

I fixed this by:

truncating descriptions sent to clustering
limiting tags
removing redundant metadata
using compact JSON
explicitly controlling completion tokens
reducing reasoning effort
limiting the result to a maximum of six meaningful clusters

After the change, repeated runs consistently generated complete, valid clusters.

The only later failures were API quota limits rather than malformed cluster output.

Prompts that worked best

The prompts that produced the strongest results were usually explicit about what not to change.

For example:

Keep the current Sanity schema and persistence behavior. Diagnose why clustering fails before changing the algorithm. Run repeated dry-run generations without modifying stored data and report the exact failure mechanism.

Or:

Replace only the image-understanding layer. Preserve Smart Capture form state, manual metadata, stale-response protection, and the existing save flow.

Those constraints kept the AI from solving one problem by accidentally rewriting an unrelated part of the product.

Sanity became more than storage

The project started with the idea that Sanity would hold saved items.

It eventually became the structural backbone of the application.

The Content Lake stores not only knowledge assets, but relationships between them:

users own saved items
saved items reference connected saved items
Knowledge Clusters reference multiple saved items
saved items can participate in multiple clusters
Rediscovery results reference both saved items and clusters

GROQ then powers:

library filtering
item lookup
duplicate detection
candidate shortlisting
cluster expansion
Rediscovery loading
per-user ownership filtering

This relational structure is what allowed the later AI features to build on one another.

Smart Connections would be much less useful without structured item references.

Rediscovery would be much less useful without first-class Knowledge Clusters.

That was the most important architectural lesson from this build.

Sanity Project Details

Sanity Project ID: jcon1mtg

Dataset: production

Echo Shelf uses Sanity as a structured Content Lake with four primary document types.

`savedItem`

Represents an individual knowledge asset.

It stores structured fields such as:

title
description
content type
source URL/text/file
image asset
tags
saved timestamp
favorite state
canonical source fingerprint
owner reference
Smart Connection references

`knowledgeCluster`

Represents an AI-discovered conceptual theme.

It stores:

title
slug
summary
tags
generated timestamp
references to constituent savedItem documents
owner reference

Cluster membership is many-to-many, so a saved item can participate in more than one theme.

`rediscoveryResult`

Represents a connection between current news and previously saved knowledge.

It stores:

news article metadata
relevance
connection type
explanation
saved-item reference
Knowledge Cluster reference
owner reference

`user`

Echo Shelf authentication is handled by Supabase.

Sanity stores only a privacy-safe user projection containing:

deterministic opaque user document ID
display name
optional avatar
creation timestamp

Raw Supabase user IDs, passwords, authentication tokens, and user emails are not stored in the Sanity user document.

Embedded Studio

Sanity Studio is embedded directly into the application at:

/studio

The user-facing product remains a fully custom Next.js interface, while Studio provides direct inspection of the underlying structured content.

Agent Session

I did not include a public Agent Session for this submission.

Instead, I maintained a detailed chronological build record throughout development:

👉 https://github.com/sheda3838/echo-shelf/blob/main/BUILD_LOG.md

It includes successful prompts, failed approaches, architectural pivots, debugging discoveries, testing notes, and production fixes.

Thanks for checking out Echo Shelf.

The project started as an attempt to make saved links easier to revisit.

It ended up becoming a system where previously saved knowledge can explain its relationships, organize itself, and reappear when something happening today makes it useful again.

DEV Community: Zaid Kamil

Before We Scroll: An AI That Gets You Off the Screen and Into the Real World

Before We Scroll: I Built an AI That Turns “Just 5 More Minutes” Into Something Real

What I Built

Demo

Live Application

Source Code

Full Engineering Build Log

I Took It Outside

Test 1 — Five Minutes Before Futsal

What it understood

Missions generated

Test 2 — A Backyard, Two Rackets, Seven Minutes

Missions generated

Test 3 — Turning a Park Into an Exploration Mission

Missions generated

The Historic Path Finder

Test 4 — No Image, Just Constraints

Test 5 — Talking Like a Normal Person

What I Learned From Testing It Outside

Code

sheda3838 / before-we-scroll

Before We Scroll

Quick Links

Project Overview

The Problem

The Solution

How I Built It

Frontend

AI

Persistence

Deployment

The AI Pipeline

1. Context Extraction

2. Mission Generation

3. Voice Input

4. Mission Narration

5. The Timer

6. Feedback and Real Outventures

Why I Benchmarked the Models

Gemma 4 26B A4B

Gemma 4 31B

Gemini 3.1 Flash Lite

Why Does Open Innovation Matter?

Prize Categories

Final Result

Try Before We Scroll

Echo Shelf 2.0: Turning Saved Knowledge Into a Living Second Brain

What I Built

Capture

Connect

Resurface

What Can Echo Shelf Save?

Smart Capture: Ground the AI Before Asking It to Think

🌐 Articles and Web Pages

🎥 YouTube Videos

💻 GitHub and GitLab Repositories

📄 Documents

🖼️ Images

📝 Notes

Gemma Is the Intelligence Layer

✨ Smart Capture

🔎 Potential Connections

🔗 Smart Connections

Stage 1 — Deterministic Candidate Selection

Stage 2 — Gemma Semantic Analysis

🧠 Knowledge Clusters

🛠️ When AI Reasoning Took Longer Than Expected

🌍 Contextual Rediscovery

Capture → Connect → Resurface

🐛 Debugging Rediscovery

🔐 Security Was Part of the Architecture

Server-Verified Identity

MongoDB Tenant Isolation

SSRF Protection

Prompt Injection Boundaries

AI Output Validation

Demo

Code

⚙️ Tech Stack

`savedItem`

`knowledgeCluster`

`rediscoveryResult`

`user`