This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
I built StudyBuddy, a local AI study assistant for my younger brother.
During exam preparation, he often has a lot of notes from his online coaching classes. The problem isn't necessarily understanding the material — it's revising all of it when there is limited time before an exam. Going through pages and pages of notes repeatedly can be difficult and time-consuming.
So I built StudyBuddy to turn those notes into short, focused flashcards that he can quickly review. He can upload his study material, generate flashcards locally, review and edit them, and export them to Anki or CSV.
The idea is simple: instead of spending valuable revision time turning notes into questions, StudyBuddy does that repetitive work and lets him focus on actually testing what he remembers.
And because it runs AI locally with Gemma through Ollama, his study material doesn't have to be sent to a third-party AI API.
Demo
StudyBuddy runs locally through Streamlit and Ollama. I'll update this post with a short video walkthrough after recording it.
Handling it Over
I gave StudyBuddy to my younger brother and had him try it with a General Knowledge PDF from his coaching classes.
He was impressed by how well the app identified the important points from his coaching material that could be useful for exam revision and turned them into focused flashcards. He did mention that flashcard generation takes some time, especially for larger PDFs, which can be frustrating.
Overall, he liked the result and wants to use it with more of his study material.
Code
How I Built It
The app is written in Python with Streamlit. For PDFs, pypdf extracts text page by page, while pasted notes follow the same processing path. The chunker groups the material into roughly 1,500-character chunks and filters out short or low-quality chunks before sending them for generation.
The generator uses Ollama's chat API in JSON mode, with Gemma 2 2B (gemma2:2b) running locally. The model is configurable through OLLAMA_MODEL, so the application isn't tightly coupled to a single model.
After each response, the app parses the generated JSON, accepts several common response formats, validates that each card contains a usable question and answer, and removes duplicate questions. If a sufficiently long chunk produces fewer than two valid cards, the app can split the chunk at a sentence boundary and retry.
The overall pipeline is:
PDF / notes → text extraction → chunking → Gemma 2 2B via Ollama → JSON validation → deduplication → review/edit → Anki or CSV export
The Study tab shows one card at a time, lets you reveal the answer, and lets you mark cards as known or needing practice. It is a simple review mode, not a spaced-repetition scheduler; Anki handles scheduling after import.
Why Does Open Innovation Matter?
For this project, local inference is useful because study materials can include paid course content or private notes. With Ollama running on the same machine, the PDF, extracted text, and generated flashcards don't need to be uploaded to a third-party AI API. Once the model is downloaded, StudyBuddy can also work without an internet connection.
Using an open-weight model also means there is no inference API key or per-request cost. The user provides the hardware needed to run the model, while having control over which Ollama-compatible model they want to use. The model is configurable rather than being locked to a proprietary hosted AI service.
For my brother's use case, this was important because I wanted to build a tool that could work directly with his study material without making a cloud AI service a required part of the workflow.
Prize Categories
Best Use of Gemma — StudyBuddy uses Google's Gemma 2 2B (gemma2:2b) as its core AI model, running locally through Ollama. Gemma transforms study material into structured question-and-answer flashcards, which are then validated, deduplicated, reviewed, and exported for studying.
Using Gemma locally is also central to the project's goal: helping my brother turn his private study material into useful revision cards without requiring a cloud AI API.
Top comments (5)
I like that you didn't stop at "LLM generates flashcards" and actually put validation and deduplication after the model. That's the part that makes this feel more like a system than just an AI wrapper.
The retry on low-quality chunks is interesting too. I'd be curious to see how much that improves recall compared with simply changing the chunk size, especially with PDFs where a single chunk can contain several unrelated concepts.
One thing I'd probably test next is whether the generated cards are actually good for learning, not just factually valid. A card can have a perfectly correct Q&A and still be a bad revision card if it's too easy, too broad, or basically gives away the answer.
Since you're already exporting to Anki, measuring things like repeated cards, answer difficulty, and which cards the user keeps getting wrong could turn this from a flashcard generator into a feedback loop for revision.
Thanks, this is a useful read.
On the retry versus chunk size question: I haven't actually tested that, and I think you're right that I should have. I picked 1,500 characters per chunk mainly for speed. Running the model on a CPU is slow, so bigger chunks meant fewer calls and less waiting. But a bigger chunk also means more unrelated ideas crammed into one request, which is probably why the model kept returning too few cards in the first place. The retry was me fixing that symptom instead of just trying a smaller chunk and seeing what happened.
The point about a card being valid but still a bad revision card is the one I keep coming back to. My validation only checks structure: is there a question, is it long enough, does it avoid a few patterns I knew were bad. It can't tell when the question gives away the answer, or when the answer runs to a paragraph. My brother's feedback after using it was that some cards were too easy, which is the exact failure you're describing and exactly what my checks can't see.
The Anki feedback loop idea is the interesting part. I think Anki stores review history in the collection database, so lapses and ease factors per card would be sitting right there. Reading that back and feeding it into generation, something like "cards phrased this way get failed repeatedly, stop producing them," would turn it into a loop rather than a one-shot. That's a real project rather than a weekend one, but it's the direction I'd take it.
Yeah, that makes sense. The CPU constraint actually makes the chunk-size trade-off much more interesting. You're not really choosing between "better chunks" and "worse chunks", you're trading context quality against inference cost.
And I think the feedback from your brother is more useful than another round of structural validation. Once you have actual review history, you can start treating the cards as data instead of assuming the generator knows what a good card looks like.
I'd probably keep generation and evaluation separate too. Let the model generate candidates, then use the review history to score patterns over time. That way you're not just teaching the model to make different cards, you're learning which kinds of cards actually work for the person using them.
That would be a pretty interesting evolution from StudyBuddy: not "AI makes flashcards", but "the system gradually learns what makes a useful flashcard for this specific learner."
flashcard generated is overall fair, but it's taking time.
Yeah, that's the price of it running on the laptop instead of a server. Roughly 15 seconds per chunk.
Two things that help: set the card target so it stops at 40 instead of doing the whole PDF, and you can start reviewing cards in the Review tab while the rest are still generating. You don't have to wait for it to finish.