I built an AI examiner that reads my friend's notes — without the notes ever leaving their laptop

A developer built Notes vs. Me, an open-source study app that turns a student's own PDFs — syllabus, lecture slides and past papers — into an AI examiner that quizzes them and tracks which topics they repeatedly fail. The app runs its entire AI loop locally via Ollama with the gemma3:1b model, keeping notes on the user's laptop and working offline, with a fallback to Groq-hosted open weights for machines that cannot run a model. The developer reports that coaxing reliable JSON out of a 1B-parameter model required a worked example in the prompt plus a coercion layer, and the full AI stack fits in roughly 1GB of RAM.

Notes vs. Me https://github.com/Priyanshujha1320/notes-vs-me is a study app with one job: take the PDFs a student already has — syllabus, lecture slides, past papers — and turn them into an examiner that grills them, question after question, then shows exactly which topics they keep failing. I built it for a friend doing their undergrad who does the thing every student does: reads the notes three times, feels prepared, walks into the exam, and discovers that reading and being asked are completely different skills. They had notes. They had questions at the back of the textbook. What they didn't have was something that looked at their notes and asked them the awkward follow-up. And here's the constraint that shaped the whole build: their laptop is where the notes live, where the revision happens, and — crucially — where the notes should stay. No student wants their past papers uploaded to somebody's cloud to "personalise their learning". So the default mode runs the entire AI loop on their machine, and it all works offline. ollama pull gemma3:1b , pip install -r requirements.txt , run — ten minutes github.com/Priyanshujha1320/notes-vs-me https://github.com/Priyanshujha1320/notes-vs-me — MIT licensed. FastAPI + SQLite + a single-file vanilla-JS frontend — no build step, nothing to trust. Six commits, one weekend. The pipeline is deliberately boring — boring is what survives exam week: The fun part was the sampling loop. A static quiz generator gets boring in about a day; a griller that remembers you failed "Calvin cycle" twice and quietly schedules it for next round behaves like something that wants you to pass. That loop is about ten lines around a weighted shuffle. The not-fun part was coaxing a 1B-parameter model into reliable JSON. Small open models copy your prompt's placeholder literally — mine happily returned "options": "A", "B", "C", "D" , letter options and all. The fix was a worked example in the prompt show, don't describe plus a coercion layer that trusts the model's actual answer type instead of fighting it. That's a trade you make with small local models, and it's worth it: the whole AI stack fits in about 1GB of RAM, so it runs on the kind of laptop students actually own. If a machine can't run a model at all, there's a fallback to the same open weights served by Groq — the app tells you, in plain words, which mode you're in. I'm handing the app to my friend this week with their own syllabus loaded — watching a real student take the first grill is the whole point of this build, and I'll update this section with what actually happens. My money is on it finding the one section they skipped. Try it on your own notes: github.com/Priyanshujha1320/notes-vs-me https://github.com/Priyanshujha1320/notes-vs-me . If it exposes a topic you were sure you knew, that's the app working. Built for the DEV Hacktoberfest Weekend Challenge https://dev.to/devteam/join-the-hacktoberfest-weekend-challenge-build-for-a-friend-2450-in-prizes-across-17-winners-1aj5 : open source AI that solves a real problem for someone you love.