"I KNOW I Saved This Somewhere": I Built MEMORY for My Best Friend Ritika

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

What I Built

My best friend Ritika is preparing for CA, and she saves everything.

Screenshots of study roadmaps. PDFs of notes. Messages with useful links. A resource someone recommended once, a tip she might need in six months, a random fact that could matter someday. If something might be useful later, Ritika saves it.

I love this about her. She's thoughtful and always thinking a few steps ahead.

But over time, "everything" turned into thousands of screenshots and files. And the problem was never saving things. The problem was finding them again.

Her phone and laptop are full of files named things like:

IMG_83921.png
Screenshot_2026_10_02.png
final_notes_2.pdf

One day she said, half joking:

"I wish there was something where I could just describe what I remember and it would find the screenshot for me."

That sentence stuck with me. She doesn't want a better folder system. She wants to say what she remembers and have the thing show up.

So I built MEMORY.

MEMORY is a privacy-first, local-first personal memory system. With it you can:

• Explicitly remember web pages through a Chrome extension
• Index and search files on your own computer: PDFs, DOCX, TXT, Markdown, CSV, and images/screenshots
• Search in natural language instead of guessing filenames

Instead of searching for Screenshot_2026_10_02.png, you ask:

"Find the screenshot about the Java internship that mentioned Spring Boot."

And MEMORY finds it.

Somewhere along the way I realized something simple:

People don't think in filenames. They think in memories.

You don't remember that the file was called IMG_83921.png. You remember what it was about.

You don't need to remember the file. You only need to remember what you remember about it.

Demo

🌐 *Live video link : * https://youtu.be/m_iiqkLiJco

🌐 Live demo: https://memory-ai-zkxv.onrender.com/

💻 GitHub: nencycodes/memory-ai

The video shows:

1. The MEMORY browser extension
2. Searching for the Java internship / Spring Boot screenshot
3. The correct screenshot being retrieved and opened
4. A second, completely unrelated image being searched and retrieved by its content

A quick honesty note about the live demo: the Render deployment is a public demo of the app. A hosted server can't reach into anyone's personal files, and it shouldn't be able to. The full local-first experience, indexing files on your own machine, runs on your own computer.

How I Built It

Here's the shape of the system:

Chrome Extension  ─┐
                   ├─► FastAPI backend ─► local memory index ─► semantic search
Local files       ─┘
(PDF, DOCX, TXT, MD, CSV, images)

The stack:

• Chrome Extension
• Python + FastAPI
• Gemma API (for explicit image understanding)
• sentence-transformers with all-MiniLM-L6-v2
• Local semantic search
• GitHub Copilot coding agent
• Render for the public demo deployment

The interesting part: screenshots

Text files are the easier case. The hard part is images, because a screenshot is just pixels until something reads it. This is the pipeline:

Image
  → Gemma image understanding
  → OCR + useful visual/contextual description
  → searchable representation
  → all-MiniLM-L6-v2 embedding
  → local memory index
  → semantic search

When you explicitly choose to index an image, Gemini reads it and produces the text in it plus a useful description of what it shows. That becomes the image's searchable representation. I then embed it locally with all-MiniLM-L6-v2 and store it in the local index.

One detail matters for both cost and privacy: Gemini is only called during explicit image indexing, not on every search. When you search, your query is embedded locally and matched against the local index.

Testing it

I tested with two screenshots:

1. A Java / Spring Boot screenshot
2. A completely unrelated cloud screenshot

I wanted to know whether MEMORY understood the content of images or whether it only worked on my first example. The unrelated screenshot was also retrieved by its content, not just its filename.

That's a small test, not a benchmark, and I'm not going to dress it up with numbers I don't have. Nothing in the system is trained or tuned for Java. The pipeline is general: whatever Gemini can read and describe becomes searchable.

Why Does Open Innovation Matter?

Think about what a personal memory system holds: screenshots of private conversations, study material, documents, things you saved because they mattered to you. For many people it's the most personal dataset they own.

My rule while building MEMORY was:

Your data belongs to you. AI should come to the data; your data should not automatically go to AI.

Open and local components make that practical. Because the embedding model (all-MiniLM-L6-v2) is open and small enough to run on a normal machine, the retrieval layer doesn't need your whole archive sitting in a cloud search system. Search happens on your device.

I want to be precise here: MEMORY is not 100% local. Gemini is used for image understanding when you explicitly index an image, so that image's content goes to the Gemini API at that moment. What is local is the semantic retrieval, the embedding layer, and the index itself.

MEMORY is designed around:

• Explicit user actions. Nothing is remembered unless you choose to remember it.
• No silent browsing-history collection.
• No automatic folder surveillance.
• Local semantic retrieval.
• User control over what gets indexed.

Not every useful AI system has to start with "upload everything." When the building blocks are open and small enough to run locally, the privacy-friendly design becomes the easy one, and a solo developer can build it.

My Agent Session

I used GitHub Copilot's coding agent as a collaborator throughout the build. It helped with:

• The FastAPI backend
• The image indexing pipeline
• Semantic search integration
• Debugging and testing
• Deployment work for the Render demo

I still made the product decisions: what MEMORY should and shouldn't do, where the privacy lines are, and how honest to be about what runs where. The agent helped me move faster on the implementation.

🔗 Agent session link (optional): [AGENT SESSION LINK]

Prize Categories

Best Use of Gemma

MEMORY uses Google's open-weight Gemma model as part of its AI-powered memory pipeline.

Gemma is used to understand and process the information that becomes part of a user's searchable memory, helping turn raw saved content into a representation that can be retrieved using natural-language queries.

Best Use of GitHub Copilot

I used GitHub Copilot's coding agent throughout development to build and iterate on the FastAPI backend, image-indexing pipeline, semantic search, testing, debugging, and deployment workflow.

What I Learned

Search is really about how people remember. I started out thinking about indexing files. I ended up thinking about how people recall things: by content, by context, by "the one that mentioned that internship." Building for Ritika made me design around how she actually thinks, not how file systems are organized.

Privacy decisions are architecture decisions. "Explicit indexing only" and "no background crawling" aren't settings you add at the end. They shape the whole design.

Being honest about the boundary builds more trust than a big claim. Writing "this part is local, this part isn't" felt less impressive at first, but it's the version I'd want to read as a user.

A small, real test beats a big, vague claim. Retrieving an unrelated screenshot by its content told me more about the pipeline than any amount of hand-waving.

What's Next?

MEMORY is a prototype, and there's a lot I want to do:

• Make setup and local indexing smoother for non-developers (Ritika should be able to use this without me)
• Add more careful evaluation of retrieval quality on larger, messier collections
• Explore fully local image understanding, to shrink the part that depends on an external API
• Improve the search experience: filters, previews, and better ways to refine "no, not that one"
• Keep every new feature behind the same rule: explicit, local-first, user-controlled

Why I Built It

I didn't want to build another chatbot.

There are already plenty of those. What I kept coming back to was something much smaller and much more human, a sentence almost everyone has said at some point:

"I remember saving this somewhere. Can you find it?"

It started with Ritika's offhand wish and a pile of files named IMG_83921.png. It became a small tool that lets you search by what you remember instead of what you named things.

I'm still early, and there's a long way to go. But if one person never has to scroll through thousands of screenshots again, it was worth building.

Built for Ritika. Built for everyone who has ever said:

"I KNOW I saved this somewhere."