DEV Community: Mohd. Ibrahim Iqbal

cubby: I made my wifi password searchable by meaning, not memory

Mohd. Ibrahim Iqbal — Wed, 21 Oct 2026 11:25:00 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

cubby is a memory bank for the things I copy and then lose: a wifi password, a docker run one-liner, a flight confirmation number, an address. You do two things with it.

Dump. Paste anything and press enter. No title, no tag, no folder.
Ask. Later, type what you remember, in your own words. They don't have to be the words you saved it with.

An open-weight embedding model, EmbeddingGemma 300M, runs inside the browser tab and ranks what you saved by meaning. There is no server, no account and no API key.

On my 20-item test set, semantic search found the right item 20 out of 20 times. Plain keyword search found it 14 out of 20. The six it missed are queries like "how do I reach the property manager" against a note that says "landlord's number: 555-0199, text don't call."

Who gets to be lazier: anyone who has ever said "I know I saved that somewhere" and then scrolled for ten minutes. The only job left for you is to paste.

Demo

Live: https://cubby-6mn8.onrender.com (first load downloads the model, about 300 MB, once)

A 10-second intro clip is in the repo.

Code

Repo: https://github.com/ibrahim-iqbal/cubby-hf26-wk3

MIT licensed. React 19 + Vite, a static site with no backend.

How I Built It

The model only measures meaning. It never writes a word.

The week before this I shipped HushQuote, which asked a 270M model to generate structured text. The write-up is mostly a list of ways it hallucinated. The lesson: a small open model is reliable at one thing, turning text into an embedding, and unreliable at writing prose. So cubby only asks it for the thing it is good at.

Job	Who does it	Why
Items that share your exact words	Plain lexical overlap (prefix / substring / exact)	Must be exact. Keyword hits are the floor the model can't drop below
Items that mean the same thing in different words	EmbeddingGemma 300M, in the browser	The one thing a small model earns its place for
Which wins when they disagree	A fixed `0.7·semantic + 0.3·lexical` blend	A tuned weight, not a per-query judgment
Writing anything in your results	Nobody	Small models hallucinate; retrieval doesn't

Saving never waits on the model. The item is written first and its vector is filled in behind it:

Asking blends two scores, so an exact keyword is never beaten by a weak semantic guess:

The test set, in full

20 fixed (dump, query) pairs. Each query is ranked against the whole 20-item corpus, so a hit means the right item rose above 19 distractors. Method and every row: test/queries.md.

Scorer	Recall@3
semantic only (EmbeddingGemma cosine)	20/20
hybrid (shipped: `0.7·semantic + 0.3·lexical`)	20/20
lexical only (plain keyword search)	14/20

Twenty items is small, and I wrote the paraphrases myself. This is a measured result on the exact case the product exists for, not a claim about harder queries at scale. I'm committing to the same fixed set for future runs rather than moving the goalposts.

The six keyword misses, for the record:

query	saved note
refund deadline for the apartment booking	Airbnb Lisbon — free cancellation until Jan 3
sherlock holmes address	123 Baker Street, London NW1 6XE
what flowers should I get for mother	mom's birthday is March 14, she likes tulips
how do I reach the property manager	landlord's number: 555-0199, text don't call
generate a self-signed TLS certificate	openssl req -x509 -newkey rsa:4096 ...
what time is my teeth cleaning	dentist appointment moved to 2:30pm Thursday

The parts that fought back

A 300 MB first load. A service worker (via vite-plugin-pwa) caches the weights, so later visits are instant and work offline. On a slow connection the first load is a real wait, so the UI shows a live log of every shard as it lands instead of a fake progress bar.
Matryoshka truncation to 256 dimensions. EmbeddingGemma emits 768-dim vectors. I keep the first 256 and renormalize, which the model is trained to allow. Each item's vector is a third the size, and recall on the test set did not change.
Task prefixes. The model is trained with task prefixes, so cubby always adds task: search result | query: to an ask and title: none | text: to a dump.
Lexical matching had to work on characters, not whole words. The first version needed a full-word match, so typing "doc" found nothing until you finished "docker". It now scores exact (1.0), prefix (0.9) and substring (0.6) per query token.
Fallback. If the model fails to load, cubby drops to keyword-only search and says so in the footer and the model card. You lose paraphrase matching, not the app.

Checking the privacy claim yourself

"Nothing uploaded" is easy to say. Here is what I actually measured on the live site, and how you can repeat it.

Open the live app with DevTools open on the Network tab.
On the very first visit you'll see the ~300 MB model download from huggingface.co. On later visits the weights come from the cache, but a small generation_config.json request to huggingface.co can still appear at page load. Hugging Face can see your IP address and browser when that happens, the same as for any web request.
Once the page has loaded, clear the log. Dump a note, ask a question, switch the theme. In my run, that produced zero new requests.

I did not test the export button. It makes a local file and has no reason to touch the network, but I haven't confirmed it.

Why Does Open Innovation Matter?

Four things in cubby only work because the weights are open:

The model is a file, not a service. The app ships it as a static asset. There is no API key, no per-call bill, no vendor who can change the pricing, and no outage that isn't mine. A hosted embedding API would have required sending every note you save to someone's server, which is the problem I set out to avoid.
I could see what was inside it. Matryoshka truncation and the task prefixes are documented behaviour of the open model, and I could test both myself. Truncating a closed model's embeddings to save space is not something I could have checked.
Privacy you can inspect. Because inference happens in your tab, the claim "your notes stay here" is something you can verify in DevTools, as above, instead of something you take on trust.
It works with no signal. The app shell and the weights are both cached. Closed APIs stop working on a plane or in a basement. This doesn't.

The Lazy Payoff

Saving costs nothing to think about. One paste and one keypress. There are no fields: no title, no tag, no folder. Every notes app I've left asked me to organize first, and that is the work I always skipped.
Finding costs one sentence. On my test set, keyword search sent me hunting in 6 queries out of 20. EmbeddingGemma sent me hunting in none (right item in the top 3).
It's fast once warm. In one run on the live site (headless browser, model already cached, one saved item), the right result was on screen about 170 ms after I entered the query. That is a single measurement, not a benchmark, and it will grow with a bigger collection.
The slow part happens once. The 300 MB download is the sloth's one big effort. After that, embedding happens quietly in the background while you carry on.

I'm not going to claim hours saved. I haven't measured that, and a number I made up would not belong in a post about checking claims.

What's honestly still missing

Text only. No images and no OCR.
No sync between devices. Export and import of JSON is the only way to move data, on purpose, because there is no server to sync through.
Hybrid ranking narrows the cases where semantic and lexical scores disagree, but it doesn't remove them.
The test set is 20 items. It is the fixed set I'll keep re-running, not proof of anything at scale.
Android Share-to-cubby is implemented through the PWA share target in the web manifest, but I have not tested it on a physical phone. iOS Safari's support for share targets is weak, so on iPhone you paste manually.

Prize Categories

Best Use of Gemma. EmbeddingGemma 300M is the whole retrieval engine. Every ranked result exists because that model embedded the note on-device, with task-prefixed inputs and 256-dim Matryoshka truncation. It never generates text.
Best Use of Render. A static site with no backend, deployed from the repo's render.yaml blueprint and redeployed on every push.

Try it

Live: https://cubby-6mn8.onrender.com
Repo: https://github.com/ibrahim-iqbal/cubby-hf26-wk3
Five themes (terminal, paper, mono, cobalt, ember), each in light and dark, checked for WCAG AA contrast with test/contrast.mjs:

HushQuote: quotes that stay yours

Mohd. Ibrahim Iqbal — Wed, 14 Oct 2026 09:49:44 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge: Week 2 - Side Hustle

What I Built: HushQuote. Speak a job description, get an itemized, editable quote - then a PDF. A small open-weight model (Gemma 3 270M) runs entirely inside the browser tab, on WebGPU when it's there and WASM when it isn't. No account, no server, no install. The client's name and the day rate never leave the device they were typed on.

Try your own phrasing, not just the demo's. If a line shows up that you never said, that's a known model quirk documented below, not a broken app - tap the × to drop it; totals recompute instantly either way.

The problem

Every tradesperson I know who works for themselves does the same thing after a job: sits in the van, opens a notes app or a half-remembered Excel template, and tries to turn "forty square meters, two days, plus materials" into something a client will actually pay against. Then they either forget a line, round a number wrong, or just don't send the quote for three days because writing it feels like a second job.

The invoicing SaaS market solved this with a $15/month subscription and an account you have to make, for software that's worse at the one job that actually matters: turning what you just said out loud into a document. That's the gap HushQuote is built for - it's cheap enough to be a real side-hustle tool, not a line item.

What I built

The whole app is one living document, not a wizard:

The Margin - a rail on the side holding your raw words in monospace, dictation-tape style.
The Sheet - an always-visible, real quote document. Line items typeset directly onto it as the model reads your words.
The Command Bar - mic or textarea, one submit button, nothing else.

Say or type the job. The model reads it into structured line items - description, quantity, unit, rate - and they land on the sheet looking exactly like what you'd hand a client, except every model-sourced line is visually provisional: a dashed border and an "Estimated. Yours to set." label, until you tap to confirm it. Math is never done by the model; totals are always computed in plain JavaScript from whatever's actually on the sheet.

A Dashboard sits in front of the Sheet once you have more than one quote going: every saved quote in one list, with stat cards for quote count, total quoted value, and how many lines across all your drafts are still sitting on a model's estimate instead of your own number.

How I built it

Stack, at a glance:

Runtime: React 19 + Vite, deployed as a static site on Render - no backend, no database, nothing running server-side at all
Model: Gemma 3 270M-instruct (Q8_0 GGUF), via wllama (llama.cpp compiled to WebAssembly/WebGPU), downloaded once into the browser tab
Validation: zod schemas (src/lib/schema.js) checking every model response before it reaches the sheet
Storage: localStorage only - quotes, business profile, and rate library never leave the device
PDF export: the browser's native print dialog, no added dependency

The model only extracts. The app decides what's true.

That's the one sentence that governs every design choice here. A 270-million-parameter model is small enough to ship as a file instead of a service, but it is also small enough to be wrong in specific, repeatable ways - so nothing it says is trusted until code checks it.

Concretely:

Structured output, not a hopeful prompt. wllama's createChatCompletion supports OAI-compatible response_format: {type:'json_schema'} natively - the model is sampling against a grammar that only lets valid tokens through, not just being asked nicely for JSON.
Everything still gets zod-validated. A grammar guarantees the braces close; it says nothing about whether the content inside them is right. Every response goes through a real schema check before it touches the sheet.
One repair generation, then honest surrender. If the first response fails validation, the model gets one more try with the exact error attached. If that fails too, the app does not guess - it drops back to manual mode and the user types the line themselves. A bad extraction costs a few seconds, never a wrong number going out silently.
The model never sees or touches the totals. Subtotal, tax, and total are pure functions over whatever line items are actually on the sheet (src/lib/totals.js) - they recompute instantly on every edit, independent of what the model ever said.

What I got wrong, and how I know

I ran all 20 of my own test transcripts (test/transcripts.md) through the real pipeline rather than trusting the two I'd eyeballed early on, and the results were worse, and more specific, than I expected.

#	Job	What happened
1, 3	Bathroom tiling (clean / with correction)	Correct
6, 16	Garden cleanup / fence staining with a price correction	Mostly correct - 16 even picked up the corrected rate, not the original
2, 7, 13	Logo package / tap repair / photography	Real job fragmented into 2-3 duplicate lines, flat fees landed in the wrong field
4, 8, 10, 11, 12, 18, 19	Fence, deck rebuild, painting, electrical, Chen deck, gutter cleaning, drywall	Right-ish first item, plus a fabricated "Callout" line that doesn't exist anywhere in the transcript
5, 17	Lawn+hedges / dog walking	Right item count, duplicated 2-5x, wrong units
9, 14	Blog posts / callout+valve	Model ignored the real transcript and echoed an unrelated internal example almost word for word
20	"Just an inspection, no numbers"	Model invented a fully priced fake quote for a job that explicitly had no numbers in it

That "Callout" line showing up in 10 of 18 fresh runs turned out to be my own few-shot example leaking into unrelated outputs - not a rate-library bug, confirmed by clearing the rate library mid-test and watching it persist. Transcript 20 is the one that actually matters: a model inventing prices for a job the user described as having none is exactly the failure "the LLM extracts, the app calculates" exists to make survivable, but a quote that reaches the pending-chip UI with a confidently wrong number on it is still a UX cost, even if it's a recoverable one.

I tried the obvious fix - dropping the few-shot example entirely and relying on the JSON schema alone. It killed both of the worst cases, but introduced a new one (the model wrote the literal string "${1}" as a description on every line). Not a clean win either way, so I shipped the known, documented behavior instead of an unproven swap days before the deadline. Full writeup, including a confirmed-separate truncation bug and its fix, is in docs/RISKS.md.

Update, after publishing: shipped the narrower fix instead. src/lib/filterHallucinations.js drops a model-output line when its description is a bare "callout" and the transcript never said any form of that word - the single leak that hit 10 of the 18 transcripts above. It's deliberately narrow: "Labor" leaks the same way sometimes, but "Labor" is correct far more often than it's a leak (transcript 1's "two days labor" needs that line to survive), so the same bare-word check there would trade a rare false positive for a common false negative. It does not touch the other two failure rows (9/14's verbatim echo, 20's fully invented quote) - those need the model to recognize it has no grounding at all, which a regex over one field can't do.

Here's the safety net those two unfixed rows still rely on, in case you hit either one: tap the × on a wrong line, the total recomputes immediately.

Why open innovation matters here

The model is a file the app ships, not a service you rent. No API key, no per-request bill, no vendor who can change pricing under you. The entire cost of running this for a thousand quotes is the same as running it for one.
Client names and day rates never leave the device. A plumber's client list is exactly the kind of data a side-hustle tool shouldn't be phoning home with, and "trust us" isn't verifiable the way "look, no network tab activity" is.
It works with no signal. A job site with no wifi and bad cell coverage is a normal Tuesday for a tradesperson. Closed APIs don't work there. This does.
Running it myself, honestly, instead of hiding the rough edges, is also the open-source story: the 20-transcript table above exists because I could actually inspect why the model did what it did, and the fixes I made (schema validation, the repair step, the token-budget bump, and now the Callout filter) are fixes to my own code, not a support ticket to a vendor.

How this is different from the other Side Hustle freelance tools

A few other Week 2 submissions land in the same space - invoice and receipt sorters for freelancers. The closest ones (InvoicePilot AI, VaultLedger AI, FreelanceAI) are all built the same way under the hood: Ollama or a Python backend the user has to install and run alongside the app. That's "local" in the sense that your data doesn't leave your machine, but it's not "no install" - you're still standing up a server process first.

The one submission actually in the same product category - turning a messy brief into a priced estimate, not sorting receipts - is ScopeCraft, a genuinely good build around Qwen3-0.6B. Even it runs a small Node HTTP server locally to serve inference. HushQuote has no server step at all, local or otherwise.

HushQuote has no backend at all, not even a local one. It's a static site. The model downloads into the browser tab itself and runs there via WebAssembly/WebGPU. Close the tab, and there's nothing left running on your machine to manage. That's a stronger version of the same privacy pitch, and it's the actual reason this is a PWA instead of a desktop app.

Prize Categories

Best Use of Gemma - Gemma 3 270M-instruct is the only model HushQuote ships, and it's the entire extraction pipeline: every line item on the sheet exists because this model read the transcript, not a cloud call standing in for it.
Best Use of Render - the live deploy (hushquote.onrender.com) is a Render static site, auto-deploying on every push to main with no build server of my own to maintain.

What's next

The deterministic regex co-extraction pass flagged in docs/RISKS.md as the next real lever on the two still-unfixed failure rows (verbatim echo, invented-quote), if there's time.
Finding an actual tradesperson to hand this to and reporting back what they asked for next - the challenge's bonus round, not done yet at time of writing.

Try it

Live: https://hushquote.onrender.com
Code: https://github.com/ibrahim-iqbal/hushquote
Full build log / decisions / bugs found: docs/PLAN.md and docs/RISKS.md in the repo - the honest version of this post, day by day.

Touch Grass: voice dares that get you off the screen, running on-device with Gemma 3 270M

Mohd. Ibrahim Iqbal — Sat, 10 Oct 2026 18:20:41 +0000

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

What I Built

Touch Grass — say how much time and energy you've got, and it gives you one short, concrete dare to go do outside. Finish it, snap a photo as proof, and it counts toward a daily streak. No feed, no infinite scroll, no "just one more dare" loop — one dare, go outside, come back later.

It's a PWA: install it, and after the first load it keeps working with no signal, because the shell and the model are both cached by a service worker.

Who it's for: anyone who opens their phone meaning to do one quick thing and surfaces 40 minutes later having done none of them. Tell it you've got 10 minutes and low energy, it won't give you a half-marathon.

Demo

🔗 Live: https://touch-grass-bkii.onrender.com
💻 Code: https://github.com/ibrahim-iqbal/touch-grass

The whole app is a little outdoor world you stand in. The painted pixel-art scene fills the screen, your character stands in the grass, and the controls sit at the edges like a game HUD — nothing floats in a box over the middle.

Flip the theme and the same world re-lights from a cozy night to a warm daytime — the backdrop art crossfades, the moon slides out and the sun comes up.

Tap the mic, say your time and energy, and a dare slides up from the bottom in a dialogue ribbon — tagged with roughly how long it takes and how much it'll cost you — with a "prove it outside" button that opens the camera.

ibrahim-iqbal / touch-grass

voice dares that get you outside — local gemma, zero backend

touch grass

voice dares that get you outside. say how much time and energy you have it gives you a short outdoor dare, you snap a photo as proof when you're done.

built for the hacktoberfest open-source ai challenge, week 1: "touch grass."

why open

dare generation runs on-device with gemma 3 270m via transformers.js, not a hosted api
works after the first load even with no signal — service worker caches the page and the model
nothing you say or type leaves your browser; your hugging face token and elevenlabs key (both optional) are stored locally and used directly from your device
swap the model, edit dares.json, or rip out the generation step entirely — it's all plain js

running it

just a static site, no build step.

python3 -m http.server 8000

open localhost:8000. voice input needs chrome or edge (web speech api support is patchy elsewhere)…

View on GitHub

Voice input needs Chrome or Edge (Web Speech API support is patchy elsewhere). Camera proof needs HTTPS or localhost — both are satisfied on the live link.

How I Built It

Plain HTML/CSS/JS, no framework, no build step, no backend. A few deliberate choices:

Default mode needs zero setup. Say your time/energy/place, it matches you against a small curated dare bank (dares.json) and speaks the result with the browser's own speechSynthesis. This always works, offline, with nothing to configure.
Optional smart layer: Gemma 3 270M via transformers.js. Paste a Hugging Face token into settings and dare generation switches to the model, running entirely in your browser via WASM — not a hosted API call. Nothing about your request ever leaves your device.
Optional voice layer: ElevenLabs, same pattern — your key, used directly from your browser, swappable back to the built-in voice at any time.
The UI is a game HUD, not a form. The painted pixel-art world fills the screen and your character stands in it; the level, stats and controls pin to the corners like an RTS, and each dare appears in a slide-up dialogue ribbon like an RPG. The backdrop art is day/night and crossfades when you toggle the theme, with a sliding sun/moon, drifting clouds and foliage that fills in as your streak grows.
A service worker caches the app shell so the whole thing — including the model, once downloaded — works with no connection after the first load. That's the actual point of the "touch grass" theme: the app should survive exactly the situation where you're outside with no signal, which is where it's most useful.
Cross-origin isolation (COOP/COEP) configured on the Render deploy so the WASM runtime gets the full, fast execution path rather than a degraded fallback.
Camera proof uses getUserMedia + canvas, with a defensive timeout — confirmed by hand that getUserMedia can hang indefinitely on a device with no camera rather than reject, which otherwise traps the UI with no way out.
Deployed on Render as a static site, auto-deploying from main on every push.

Why Does Open Innovation Matter?

Two reasons this specific shape only works because the model is open-weight:

It can genuinely run with nothing hosted by me. There's no backend, no API key of mine in the loop, no bill that scales with usage. A user who wants the smarter dare generation brings their own free Hugging Face token and the model downloads and runs on their device. I can't see their request, because it never reaches a server I control. A closed API would force a hosted proxy — which means a cost center, a privacy boundary I'd be asking users to trust, and a single point of failure the moment I stop paying the bill.

It made "fully optional" actually honest. Because Gemma 3 270M is small enough to run client-side, the "smart" mode isn't a crippled free tier nudging you toward a paywall — it's a real optional upgrade with a real reliability floor underneath it (the curated dare bank) that works identically whether or not you ever touch the settings gear. That's a hard thing to build honestly on top of a closed, metered API; it's the default shape of an open-weight one.

Prize Categories

Best Use of Render — static site, deployed and auto-deploying from this repo, with COOP/COEP headers configured for the WASM runtime
Best Use of Gemma — Gemma 3 270M running fully client-side via transformers.js for live dare generation
Best Use of ElevenLabs — optional nicer voice output for the spoken dare, key used directly from the browser

OSS Buddy: a local Gemma that picks weekend-sized issues so my cousin can finally land his first PR

Mohd. Ibrahim Iqbal — Fri, 02 Oct 2026 17:52:59 +0000

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

What I Built

I have a cousin. He has been telling me he wants to contribute to open source for about a year. Every month or two he sends me a screenshot of a repo and asks "is this a good one to start with?" I say yes. He opens it, scrolls for twenty minutes, closes the tab. The screenshot never turns into a PR.

I used to tell him "just pick a good first issue." That advice is useless. Good first issues live in repos with four hundred files and eighty open issues each. You still have to pick. He had already been doing that for a year.

So I built OSS Buddy. You point it at any GitHub repo and a local Gemma 3 model tells you three things in about twenty-three seconds:

What the project actually does, in two plain sentences
Up to three good first issue tickets ranked easiest to hardest, with time estimates
Which specific directory to start reading

Nothing leaves his laptop. No account, no API key, no credit card. He downloads Gemma once, forgets about it, the tool works forever.

Demo

One command, no cloud calls. Terminal recording against kiwix/kiwix-android.

Benchmarks on five real repos

Measured end-to-end on an M-series Mac with Gemma 3 4B via Ollama. Each run is one command, no warmup, no cache.

Repo	Stack	Runtime	Good-first-issues found
kiwix/kiwix-android	Kotlin	27.9s	6
simonoppowa/OpenNutriTracker	Flutter	23.5s	3
RetroMusicPlayer/RetroMusicPlayer	Kotlin	22.1s	6
neovim/neovim	C	22.0s	0 (no `good first issue` label)
fastapi/fastapi	Python	22.0s	0 (none open at test time)

Average: ~23 seconds, zero cloud bytes. The two zeros are honest limits — neovim doesn't use the good first issue label at all, and fastapi had none open when I ran it. OSS Buddy says so plainly rather than hallucinating issues.

Code

ibrahim-iqbal / oss-buddy

A local Gemma 3 reads any GitHub repo and picks weekend-sized good-first-issues for your friend. Nothing leaves your machine.

OSS Buddy

Point it at a GitHub repo. A local Gemma 3 model reads the README, the top-level file tree, and the open good first issue tickets, then tells you:

What the project does, in plain words
Up to three issues that look weekend-sized, ranked easiest to hardest
Where in the repo to start reading

Nothing leaves your machine. Your GitHub token stays local. The model runs on your laptop via Ollama.

Why

A friend of mine kept opening huge OSS repos, scrolling for twenty minutes, closing the tab. He wanted to contribute. He did not know where to start. Every guide said "pick a good first issue" and every repo had dozens.

This reads the repo for him and says "here, pick one of these three start reading here."

Install

Needs Python 3.9+, the GitHub CLI, and Ollama.

# ollama (macOS)
brew install ollama
brew services start ollama

…

View on GitHub

~150 lines of stdlib Python. No pip install. MIT.

How I Built It

Open-source AI used:

Gemma 3 (4B) — Google's open-weight model, running on my laptop
Ollama — open-source runtime for the model
GitHub CLI (gh) for repo data

Pipeline (lazy on purpose):

    gh api  (readme + top-level tree + good-first-issues)
                        │
                        ▼
                 one tuned prompt
                        │
                        ▼
         POST localhost:11434 (ollama)
                        │
                        ▼
                   gemma 3 4b
                        │
                        ▼
         stream the answer to the terminal

Three HTTP calls to GitHub, one HTTP call to a server running on my own laptop. That is the whole pipeline. The Python file is small enough to read in one sitting.

The prompt went through three real iterations in the git history. The first version produced great summaries but ended every answer with "Would you like me to delve deeper?" — chatty, off-brand. The second version started paraphrasing issue titles instead of quoting them, which was worse than useless because then you couldn't grep for the issue on GitHub. The third version pins Gemma: "Quote the issue number and the EXACT title from the data below. Do not paraphrase or invent." That one shipped.

Labels aren't consistent across repos

Early version only looked for the literal good first issue label. Lost half the repos. The fix was a cheap one — try the three common spellings in order:

for label in ("good first issue", "good-first-issue", "beginner"):
    ...

Simple, but it is the difference between the tool working on one repo in two and almost all of them.

Why Does Open Innovation Matter?

He does not need to sign up for anything before he can start contributing to open source. He already has GitHub, git, and a dozen tabs open. A new contributor does not need another sign-up flow before the one he actually came for. Open-source AI removes that friction entirely — he downloads the model once, forgets about it, and the tool just works.

The second thing matters more. His GitHub token and the repos he explores never leave his laptop. Some of those repos are private — half-built side projects, work stuff. A closed API would have meant sending every README and every issue title to a third party's servers. With Gemma running locally that whole class of problem does not exist.

The third thing is practical. It runs on a plane. It runs in a cafe with slow wifi. It runs inside offices that block third-party API calls. It costs zero rupees forever. For someone taking their first step into open source every friction point is a chance to quit — the open stack removes a few of them.

And the whole chain is readable. 150 lines of Python. An open-weight model with public weights. A runtime with public source. If my cousin wants to see what the LLM did with his repo, he can trace it from his terminal all the way down to the weights. That is the open-source story — not just the model, the whole stack.

The hand-over

I sent him the install snippet on WhatsApp — three commands, no sign-up, no API key.

He hasn't run it yet as of this edit. I'd rather say that plainly than leave a placeholder sitting in a published post. The honest version of "built for a friend" includes the part where the friend hasn't gotten to it yet — that's a real, common outcome of building something for someone else's spare time, not a reason to dress it up. I'll update this section the moment he does, with whatever he actually says, not a tidied-up version of it.

My Agent Session

Skipping DevRelay sessions on this one. The story is in the git log instead:

31b5e08 initial scaffold: fetch readme + good-first-issues via gh
4a8dbb5 wire up ollama + first prompt that asks for 3 ranked issues
ede3d7f tighten prompt (no outro, quote exact issue titles)
b430d72 add demo gif + vhs tape
bf1babc readme: link to the dev.to writeup
0d26567 readme: proper case + benchmarks table + cover image

Six commits, a few hours of work spread across one evening and the next morning.

What's next

Short list, in the order I'd attack them:

Deeper issue analysis. Right now it reads the issue title and body. Next step: fetch linked files and the diff of the last PR to touch them, so "where to start" becomes line-level, not directory-level.
Remember what my cousin has already tried. A tiny local SQLite log of attempted issues so OSS Buddy stops suggesting the same ones.
A thin web wrapper for people without Ollama. Deployed somewhere small (likely a free Render tier) that calls a hosted Gemma via Groq. The CLI stays local-first; the web version is a convenience.
A --contributing flag that reads the project's CONTRIBUTING.md and tells you what tests to run and how to open a PR, so the suggestion ends with "and here is exactly how this project wants it submitted."

None of it changes the shape of the tool. It's all deeper reading of the same three sources.

Prize Categories

Best Use of Gemma — Gemma 3 (4B) via Ollama is the only model used. The entire pipeline depends on it. No fallback, no closed-model path, no "bring your own API key." Just Gemma, local, free.