Hacktoberfest Weekend Challenge: Build for a Friend (devmemory)

Naresh Kumawat — Sun, 04 Oct 2026 08:08:32 +0000

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

What I Built

DevMemory is a personal coding-memory app. You log the bugs you actually hit — the snippet, the error, and what you learned — and it turns that pile of mistakes into an AI that answers you, grounded in your history.

I built it for my friend Rahul, who is learning to code. His problem was never "I can't find an answer." It was that he kept making the same class of mistake over and over — an off-by-one here, a missing null check there, a Python ternary precedence bug he'd already fixed two weeks earlier. He'd fix it, forget it, and then hit a near-identical variant in a different project. Existing tools (Stack Overflow, ChatGPT) give generic answers because they don't know what he already got wrong.

DevMemory is the thing that remembers for him. Every mistake he saves makes the next answer sharper.

Six capabilities:

AI root-cause analysis — paste a snippet + stack trace, and Gemma extracts the real root cause, severity, and the lesson (not just the symptom).

Semantic search over his own memories — MongoDB Atlas Vector Search matches by logic pattern, not keywords, so "list index out of range" finds his old off-by-one fix. Grounded Q&A — ask "why does my recursion blow the stack?" and get an answer built only from bugs he has personally hit. Recurring-bug detection — every error is tagged and categorized so anti-patterns surface automatically. Progress analytics — mistake frequency, severity trends, and a topic-weakness radar over days, weeks, and months. Personalized practice — generates a fresh coding problem aimed at the exact concepts he struggles with most.

The pipeline, end to end:

01 Save Memory → log snippet + problem description + thrown error
02 AI Analysis → Gemma extracts root cause, difficulty, key takeaways
03 Vector Embed → chunks + embeddings stored in MongoDB Atlas
04 Semantic Retrieval → Atlas Vector Search pulls relevant past memories
05 Grounded Answer → Gemma answers, strictly grounded in his own history

Demo

Deployed link:https://devmemory-sdsp.onrender.com/
Video walkthrough:https://screenapp.io/app/files/6ac208e300322e29fc6a6f0a
Code
GitHub: Nareshkumawat-star/devmemory

How I Built It

evMemory is built around Gemma, an open-weight model from Google. Gemma does the thinking: root-cause analysis of a stack trace, recurring-mistake detection, the personalized explanations, the practice-problem generation, and the grounded Q&A. It talks to my app over a plain OpenAI-compatible /chat/completions interface, which turned out to be the most important design decision in the whole project.

For retrieval, I use an OpenAI-compatible embedding endpoint to chunk and embed each memory, store the vectors in MongoDB Atlas, and retrieve them with Atlas Vector Search. Gemma then answers strictly from what retrieval returned — so it can't hallucinate advice about code my friend never wrote.

Architecture

Next.js (UI + route handlers)
│
├── MongoDB Atlas ──────────── Vector Search
│ ▲ │
│ │ embeddings │ retrieved memories
│ embedding API ▼
└──────────────► Gemma ──────► grounded answer

How it was actually built (and where the AI agent came in)

I built this with Codebuff as my agent, working through it in small, verifiable steps:

Scaffolded the Next.js 16 App Router app, Zod schemas, and MongoDB connection layer.
Built the memory CRUD + Monaco editor, then the analyze endpoint (Gemma analysis → embed → vector upsert).
Added the RAG pipeline and wired /api/ai/ask and /api/ai/practice on top of it.
Built the analytics dashboard with Recharts and the improvement timeline.
Hardened it: 68 unit tests, Playwright E2E, tsc --noEmit, ESLint.
Deployed to Render on the free plan with a render.yaml blueprint + a multi-stage Dockerfile, and pointed Mongo at Atlas.

Deployment lessons I hit along the way (in case they help someone else):

Next.js 16 warns that next start is unsupported when output: "standalone" is set at build time — so I gate it behind an env flag and only enable it for Docker.
On Render, setting NODE_ENV=production makes npm ci skip devDependencies, which breaks the build (Tailwind's PostCSS plugin lives in devDeps). The fix is npm ci --include=dev && npm run build.
@types/node had to move to ^24 to satisfy a Vitest 5 peer requirement, and the lockfile had to be regenerated with the same npm major as the build container.

Why Does Open Innovation Matter?

My Agent Session

This project only works because the model is open. Three concrete reasons:

1. The inference host is swappable, with zero code changes. Because DevMemory speaks the plain OpenAI-compatible shape, the exact same code runs against a local Ollama instance, a self-hosted vLLM server, or any hosted provider. That's not a nice-to-have — it's the difference between the app working and not working. During development my friend runs Gemma locally for free and offline; in production it points at a hosted endpoint. One environment variable changes, and the feature set is identical. A closed API locks you to one company's servers, one company's price, and one company's uptime.

2. Privacy is a feature, not a footnote. The whole premise is my friend logging his real mistakes — the code he's embarrassed about, the bugs from his actual projects. With open weights he can run the entire thing on his own machine and nothing ever leaves it. With a closed API, every personal coding mistake is posted to someone else's server. For a "personal memory" app, that's a fundamental difference.

3. Open weights let the app stay free. A hobby project for one friend can't subsidise per-token API costs. Being able to run the open model locally, or point at a free hosted endpoint, is what makes DevMemory viable as a gift rather than a subscription.

More broadly, open innovation is what makes the RAG pattern accessible at all. The embedding pipeline, the vector store, and the model are three independent choices, each replaceable. That composability — being able to hold the whole stack in your head and swap any piece — is exactly what closed, vertically-integrated AI platforms take away.

My Agent Session

I built DevMemory with Codebuff / Freebuff as my coding agent.

The agent handled the full loop with me: scaffolding the App Router structure, writing the Zod schemas and the MongoDB RAG layer, implementing the Gemma client, building the analytics UI, writing the Vitest + Playwright tests, and debugging the Render deploy (the devDependencies/Tailwind build failure and the @types/node peer conflict both surfaced through the agent's test-and-verify cycle).

team leader (username):nareshkumawatstar

DEV Community: Naresh Kumawat

Hacktoberfest Weekend Challenge: Build for a Friend (devmemory)

What I Built

How I Built It

Why Does Open Innovation Matter?

My Agent Session

My Agent Session