DEV Community: Bipul Chamoli

Availazy: Gemma 4 forgot to cancel Thursday. A keyword list didn’t.

Bipul Chamoli — Fri, 23 Oct 2026 15:19:32 +0000

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

🦥 TL;DR. Paste a week of volunteer chat messages. Gemma 4, running locally in Ollama, copies the words that matter ("Tuesday", "after 3", "if my work shift gets moved"). Plain Python turns them into dates, times and a day-by-day history. You accept or reject each suggestion beside the message it came from, and only what you accept reaches the final sheet.

▶️ 5:48 demo · 🧪 Try the replay in your browser · 💻 Code, MIT licence

Thursday, 9:10 a.m.

On Monday, Maria posts in the volunteer group chat:

I can do Tuesday and Thursday mornings.

On Thursday she posts again:

Change of plans — Thursday doesn't work anymore, sorry! Tuesday morning still good. I can add Friday 2-5.

There are 48 more messages that week. Priya can do "Monday after 3". Kofi "might be able to do Thursday afternoon if my work shift gets moved". Rui writes "Next Tuesday" on a Monday, which could mean tomorrow or the Tuesday after. Somebody has to read all of it, remember who changed their mind, and type it into a sheet. Then somebody changes their mind again.

Riverside Community Pantry doesn't exist. The pantry, its 18 volunteers and all 50 messages are invented, so this could be built and tested without touching anyone's real chat. But if you've ever coordinated volunteers, you've lived this week.

What I Built

Availazy is a local review tool for the person who asks "when can you help?" and then has to make sense of the answers.

Availazy turns volunteer messages into suggestions you can review beside their source.

You paste dated chat messages (or a WhatsApp text export) and your volunteer list, pick the week, and Availazy:

📝 suggests availability records, each shown beside its message with the quoted words highlighted;
🔁 keeps everyone's history day by day, so a correction replaces the earlier answer, a cancellation removes it, and a "maybe" stays a maybe until the person confirms;
✋ refuses to guess. Anything the words don't settle goes on a Needs a decision list;
✅ exports a final sheet built only from what you accepted. It says complete only when every message is marked reviewed, nothing is pending and nothing is unresolved. Otherwise it says provisional, and it still downloads.

It records availability, not shift assignments. The person who gets to be lazy is the coordinator: they stop retyping and start deciding.

Demo

For readable interface details, select ⚙️ → Quality → 1080p HD.

The video opens with the local app: Gemma 4 reads two invented messages live, through Ollama, on my laptop. Then it switches to the hosted replay for the full week.

Try it yourself: https://availability-ledger-replay.onrender.com/app. This is a replay, not live inference. It serves the fictional week with Gemma's answers saved in advance, so it runs on free hosting without a model. Reviewing, history, the chart and both exports all work; pasting your own messages is switched off. Free hosting sleeps when idle, so the first visit can take about a minute.

There's also an illustrated guide with diagrams at /docs.

Gemma missed Maria's cancellation. That's the point.

When Gemma read Maria's Thursday message in the saved run, it got her Tuesday right and her new Friday right, and it missed the cancellation completely.

So Availazy doesn't trust one reader. In the default mode, a plain keyword reader reads every message alongside the model. When the rules see a cancellation the model didn't, the app adds it, flagged, so I can check it:

Gemma found Tuesday and Friday. The rules added the Thursday cancellation for review.

Until I accept it, the sheet shows Thursday as a pending change. One click on Accept and Thursday is gone from the final sheet. In Model only mode, the same replay leaves Maria on Thursday morning. That one message is the whole argument for running two readers.

How I Built It: the model reads, code decides

The design is one strict split:

message ──▶ Gemma 4 E2B (Ollama, local) ──▶ copied words + a proposed status
        └─▶ keyword rules ─────────────────▶ a second opinion
                         │
                         ▼
     Python: who, which date, which hours, does the quote exist,
             what does this replace, what is still unsure
                         │
                         ▼
     You: accept / reject / edit, mark each message reviewed
                         │
                         ▼
     Final sheet (accepted records only) + review log

1. Gemma copies words; it doesn't do dates. For each message, Gemma fills a JSON schema that Ollama enforces. This is its real saved answer for Maria's "Tuesday morning still good":

{"person": "SENDER", "day_text": "Tuesday", "time_text": "morning",
 "status": "available", "condition": "", "replaces_earlier": false,
 "excerpt": "Tuesday morning still good"}

No date and no hours, just the words. Gemma didn't even mark it as a replacement ("replaces_earlier": false). Python spotted "Change of plans" and marked Maria's new answers as replacing her old ones, with a visible note on each card. Python also works out that "Tuesday", sent on Thursday 5 November for the week of 9 November, means 10 November, and that "morning" means a fixed window:

DEFAULT_PERIODS = {
    "morning": ("09:00", "12:00"),
    "afternoon": ("13:00", "17:00"),
    "evening": ("17:00", "20:00"),
}

Open ranges are code too. "After 3" runs to 20:00, the end of the planning day, and the card says so:

“After 3” becomes 15:00–20:00, with the assumption written on the card.

2. Every quote is checked against the message. If the model's quote and its day/time words are both missing from the message, the suggestion is not applied unless you choose "Use it anyway". If only some words are missing, it's flagged.

3. History is kept in order. Later messages change only the days and times they mention. Kofi's "if my work shift gets moved" stays conditional until his later "my shift got moved, so Thursday afternoon is a yes". Olu's "I have to drop out for the rest of this week", sent on a Wednesday, cancels Wednesday through Sunday, taking out his Thursday evening and Saturday morning:

An excerpt of the change history, with replacements and cancellations linked to their source messages.

4. When the words don't settle it, it asks. "Next Tuesday" sent on a Monday could be two dates. "This Saturday" sent the week before is outside the week. A name that matches nobody on the roster isn't guessed:

Ambiguous dates, unmatched names and unresolved conditions stay on the decision list.

5. The calm wrong answer. Marta asks: "Is Maria still doing Tuesday morning? If not I can take it." Gemma filed Marta's offer under Maria, as a conditional Tuesday. It's wrong, and it looks perfectly reasonable. That's why every suggestion sits beside its message, and why this one carries "Only one of the two readers found this":

Marta wrote the message, but Gemma assigned the offer to Maria. Reviewing the source makes the mistake visible.

One click on Reject and Maria's Tuesday is firm again.

Update, 24 Oct: after a reader's comment, Availazy now also warns when a suggestion is for someone other than the sender, or when the message names another volunteer. Both warnings block one-click accept, so it now takes 36 suggestions instead of the 39 shown in the video.

6. Only accepted records reach the sheet. Here are the first rows of the real export from the replay, after I accepted Maria's cancellation, rejected the m48 mix-up, accepted the 36 warning-free suggestions and marked two messages reviewed:

# availability-final v1; week=2026-11-09; status=provisional; unreviewed=m01 m03 … m50; pending=24; blocking_issues=0
volunteer,date,start,end,status,condition,cell_state,sources
Maria Lopez,2026-11-10,09:00,12:00,available,,confirmed,m28.1
Maria Lopez,2026-11-13,14:00,17:00,available,,confirmed,m28.2
Marta Lopes,2026-11-09,09:00,12:00,available,,needs_review,m17.1

(The unreviewed list is shortened here.) Maria has Tuesday and Friday, and no Thursday. Her messages are marked reviewed, so her cells are confirmed. Everyone else is needs_review, and the whole file honestly says provisional.

The stack is boring on purpose: a Python standard-library server, plain HTML/CSS/JS with no framework or CDN, and Ollama on 127.0.0.1. The only optional dependency is sentry-sdk, for opt-in tracing.

The Lazy Payoff 🦥

Here's the fictional week, by the numbers, from the replay:


Messages	50 (one exact repeat is collapsed automatically)
Suggestions, each beside its quote	67
Accepted with one click (no warnings)	36
Left for a real decision (a warning, or not applied)	31
Items on the Needs a decision list	10
Gemma + rules reading the week on my 8 GB Apple M2	131 s end to end (one dated run, not a benchmark)

After the one-click accept: dark green is accepted, light green still waits for review, striped orange is conditional.

So the work shifts from reading 50 messages and typing a sheet to checking 31 flagged suggestions, each with its quote right next to it. The model reads the whole week in about two minutes: long enough to make a cup of tea.

I haven't timed a real coordinator, so I won't claim minutes saved. The repo has a written protocol for that study; it hasn't been run.

How well does it work?

I didn't want to grade my own homework, so a separate ChatGPT session wrote a test week I'd never seen (set C: 24 fictional messages; I rewrote five of them). Its files were frozen by hash before any implementing agent saw them, and then it was scored once. That first score is kept exactly as it came out:

Reader	Person-days right	Silent errors	Cancellations missed on the sheet	Sheet agreement with the answer key
Keyword rules only	15/20	5	4/8	0.433
Gemma 4 E2B only	17/20	2	4/8	0.403
Gemma 4 E2B + rules	17/20	2	2/8	0.527

All suggestions were left pending and nobody reviewed them: this scores the draft sheet before a human touches it.

Four things I didn't expect:

The keyword list earned its seat. On the sheet, rules alone (0.433) actually beat Gemma alone (0.403). Gemma read more person-days right, but each reader caught things the other missed. Together they halved the missed cancellations.
"Mostly right" can still make a wrong sheet. Gemma + rules read 17 of 20 person-days right, yet the sheet matched only about half the time slots. The biggest culprit was "Please change my availability on monday to 1-4 pm". The hours were right, but nothing treated it as a replacement, because "change" wasn't one of my replacement words. So the old all-day Monday stayed underneath.
Every fix went into Python, not the prompt. The prompt is the same version that was scored. Five deterministic fixes followed: explicit dates beat weekday words, "change" became a replacement cue, a firm follow-up settles a maybe, "T. Vekar" is an ambiguity rather than a stranger, and the rules learned more negations. Re-scored from the same saved Gemma outputs, set C now reaches 1.0, but I label that post-hoc: I fixed what I'd seen, so it proves little about new messages.
Honest numbers are less impressive and more useful. An earlier set B (20 messages) scored 30/35 person-days and 0.776 sheet agreement on its first scoring. Every frozen table, every caveat and every after-the-fact change is in RESULTS.md.

Built with

🧠 Gemma 4 E2B (gemma4:e2b-it-qat, Apache 2.0) in Ollama. About a 4.3 GB download and about 1.6 GB of memory once loaded on my 8 GB Mac, so it runs alongside a browser. It's the reader in the local app, and it produced every saved answer in the replay.
☁️ Render hosts the fictional replay, so judges can click through a full week without installing anything. The server runs in a demo mode that refuses any message, roster or week it didn't serve, and it never calls a model.
✅ GitHub Actions runs on every push and pull request to main, with three jobs: 128 unit tests (8 tracing tests skip without the optional SDK); a SHA-256 check that the frozen evaluation results haven't been touched; and a re-score of all three test sets from the saved model outputs, with no model calls. Run #29 passed all three jobs.
🔭 Sentry Agent Tracing is opt-in and off by default. When on, two allowlists in my adapter limit what's sent to structure: timings, token counts, model and stage names. Message text, names, quotes, prompts and replies are excluded, and offline tests check that planted fake content never appears. The traces earned their keep. In one run, four model calls hit the 300-second client deadline waiting for Ollama. A later run made 49 calls in 1.42 minutes with no errors. (The traces don't say why the earlier calls stalled, and I won't pretend they do.) One caveat I found: received traces showed location (geo) attributes that my code doesn't send. After a settings change, the four I inspected appeared filtered, but I haven't audited everything Sentry receives (dated evidence).

One traced run: four Gemma calls in a row each hit the 5-minute client timeout. The selected call shows "No input for this span": no message text was sent.

Every push to main runs three jobs: unit tests, a SHA-256 check of the frozen evidence, and a re-score from saved Gemma replies with no model calls.

The replay is one free Render web service, managed by a Blueprint. Every push to main auto-deploys it, including the commit that added the new sender warnings (84d5fec).

bipul724 / availability-ledger

Availazy

Local AI for Coordinators Who Have Better Things to Do. Let AI read. You decide.

Availazy was called Availability Ledger until 2026-10-22 (BRAND-01). The repository and Render service keep their existing availability-ledger identifiers; the Sentry organization remains availability-ledger and its project remains python. Older records in this repository use the old product name.

A local review tool for volunteer coordinators who collect availability through ordinary messages. You paste a week of dated chat messages and your volunteer roster; the tool suggests availability records, shows each one beside the message it came from, and keeps a per-person, per-day history of offers, corrections, cancellations and conditions. You review the suggestions, explicitly mark each message reviewed, and export a reconciled final sheet built from accepted records. A separate review log preserves the record trail.

It records availability (when people say they can or cannot help), not shift assignments.

A local open…

View on GitHub

Why Does Open Innovation Matter?

Volunteer availability is quietly personal. "I'm at a wedding." "If my work shift gets moved." Read together, a week of these messages maps people's families, jobs and lives. Here's what an open model on the coordinator's own laptop makes possible:

The messages stay on the computer. In the local app they go only to Ollama on 127.0.0.1. There's no cloud AI service in the loop, and optional tracing is off unless you turn it on.
No account, no API key, no per-message bill. Once Ollama and the model are installed, it works offline. A small food pantry can afford "free forever".
It fits the hardware people actually have. An 8 GB laptop is enough, so the volunteer coordinator doesn't need a GPU or a budget.
It can be checked. The prompt, the schema, the rules, the test sets and the frozen scores are all in the repo. Anyone can re-score them from the saved outputs without running a model, which is exactly what CI does.
It can be swapped. The model is a menu choice of whatever Ollama has installed. I also evaluated Qwen3.5 4B against the same answer keys.

A hosted API might be smarter. But the right answer to "where do my volunteers' messages go?" should be "nowhere".

What it can't do (yet)

It has only seen fictional messages. No real coordinator has used it, and the test sets share an author with the code, except set C.
Times are read as written; the timezone field is stored but not converted. "At 9" isn't read.
Up to 20 volunteers, one browser tab, and nothing is saved between sessions.
The keyword reader still misreads some phrasings. It read "Saturday 9–12 if it isn't raining" as unavailable instead of conditional, which is exactly why every suggestion sits beside its message.
Not tested in Safari, Firefox or with a screen reader.

Prize Categories

Best Use of Gemma: Gemma 4 E2B is the local reader, held to a strict "copy the words, code does the maths" contract, measured against a rules baseline and a frozen test set written by a separate AI session.
Best Use of Render: the interactive replay that lets anyone review a full fictional week without installing a model.
Best Use of GitHub Copilot (via GitHub Actions): unit tests, a frozen-evidence integrity check and a cache-only re-score of every test set on every push and pull request.
Best Use of Sentry Agent Tracing: opt-in, content-free model-call traces that surfaced the 300-second timeouts.

Slow and steady: the model reads, the code reconciles, and a person decides. If you coordinate volunteers, how do you collect availability today, and what's the message that always breaks your spreadsheet? 🦥

"red label adha kg 2 box": an offline WhatsApp order reader for Indian shops that asks before it guesses

Bipul Chamoli — Fri, 16 Oct 2026 14:06:31 +0000

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

TL;DR: Small Indian shops get orders on WhatsApp in a mix of Hindi, English and shorthand. ParchiMatch Lite turns each line into a checked billing row, on the shop's own 8 GB laptop with the Wi-Fi off. When it isn't sure, it asks one short question instead of guessing. On 80 locked test orders it filled in 0 wrong rows, and on messages my friends typed by hand, also 0.

What I Built

This is built for small Indian stores. Their orders come in on WhatsApp, and one message can mix Hindi, English and abbreviations:

Namaste bhaiya
kit kat 10/- darjan 4
red label adha kg 2 box
12 pack lais peela 10 wala
teen petti marrie 10 rs
Kal subah tak bhej dena

Someone has to retype every line into billing software like Tally, Busy or Marg. Petti is a carton, darjan a dozen, adha kg half a kilo, lais peela the yellow Lay's. And if a line is matched to the wrong product, that's expensive: the wrong stock gets packed, billed and put on the van.

So I tried to build something that needs minimal input from a person, but asks for their full attention exactly where a mistake would cost money. It reads each line, matches it to the shop's own catalogue, and sorts it into one of three colours:


🟩 Green	Matched and checked: `teen petti marrie 10 rs` → 3 cartons of Marie ₹10 (180 packets)
🟧 Amber	Not sure, so it asks one short question with its best guess filled in: `marie 30 wala 20 jodi` → What is "jodi"? packet or carton?
⬜ Grey	Greetings and notes, ignored: `Kal subah tak bhej dena`

Then it exports a CSV for the billing software. It also learns the shop's own words: confirm "lais peela" once with Remember ticked, and next time it goes straight through.

The rule behind everything: a wrong row must never be filled in on its own. When unsure, ask. A shop owner forgives a question. They don't forgive a wrong delivery.

Who would pay: small FMCG wholesalers and kirana suppliers who get dozens of WhatsApp orders a day and pay someone to retype them. It runs on the laptop they already have, works without internet, and costs nothing per order.

Pricing (an untested guess): around ₹299 a month per shop. I haven't put this price in front of a real shop yet; that's the first thing I'll test.

Demo

The whole video is recorded with Wi-Fi off, on a MacBook Air M2 with 8 GB of RAM. Even the project site in the last minute is served from the laptop. What you'll see:

A real-looking order, matched in about 8 seconds: 6 lines green, 5 amber, 2 notes.
The model's guess can be wrong, and that's why it asks: for "lais peela" (the yellow Lay's) it suggests Magic Masala, but yellow is Classic Salted. One tap to pick the right one, and tick Remember.
It learns: after export it says "Learned 3 new names", and the same order comes back with 8 green lines instead of 6, with the corrected products.
Four tricky lines, and what the app does with each:

I typed	What happened	Why
`aashirvaad atta 10 kg 1,500 bag`	🟩 1,500 bags	An early version read this as 1 bag and accepted it (see What I got wrong)
`maggi 1,5 pkt`	🟧 What does "1,5" mean?	An unclear number is never guessed
`red label adha kg 2 box`	🟧 Is it Brooke Bond Red Label (250 g)?	The model guessed 250 g; adha kg means 500 g. The code saw two sizes fit and asked
`पारले जी 5 वाला 2 पेटी`	🟩 2 cartons Parle-G ₹5 (288 packets)	Hindi in Devanagari works too

Project site: https://bipul724.github.io/parchimatch/

Code

bipul724 / parchimatch

ParchiMatch Lite

Messy wholesale orders → clean billing rows, on the shop's own computer.

A small FMCG wholesaler gets orders like these on WhatsApp:

Namaste bhaiya
parle g 5/- 2 petti
tata namak 1 kg 5 ctn, lays hara 10 rs 3 box
पारले जी 5 वाला 2 पेटी
fortune oil 2
Kal subah tak bhej dena

Someone retypes every line into Tally, Busy or Marg. ParchiMatch Lite reads each line, matches it to the shop's own catalogue, and either fills in a checked row or asks one short question. It never guesses a number, and it never auto-accepts a row it can't justify. It runs fully offline with an open-weight model on an 8 GB laptop.

🟩 Green	Matched and checked: `parle g 5/- 2 petti` → 2 cartons Parle-G ₹5 (288 packets)
🟧 Amber	One question, best guess pre-filled: `marie 30 wala 20 jodi` → What is

…

View on GitHub

Zero npm dependencies; Node 24 runs the TypeScript directly. To try it: npm run app -- --open.

How I Built It

The model only picks the product. My code reads every number.

Small models are good at "which product did they mean?" and unreliable at "is petti a packet or a carton?". So the work is split:

Code reads every number: quantities, unit words (petti, ctn, darjan, bori…), prices (5/-, 10 rs), pack sizes (1 kg, 500ml), Hindi number words (teen, paanch).
Fuzzy text matching handles most lines instantly, with no model at all.
Only when fuzzy matching can't decide does the local model see the line plus the 8 closest products. It answers in strict JSON, at temperature 0, and can only pick one of those 8.
16 safety rules in code check the pick: does the price match? The pack size? Is the product sold in that unit? Any failed check turns the row amber, and the question is written by the code, not the model.

Choosing the model: I tested five

On my 8 GB MacBook I tried five open-weight models in that "decider" role, on 320 synthetic practice orders:

Model	Auto-accepted	No typing needed	Right suggestion on amber rows	Typical / slowest
Gemma 4 E2B (chosen)	88.7%	96.1%	65.2%	3.1 s / 9.2 s
Qwen3.5 2B	88.7%	94.6%	52.2%	2.5 s / 3.3 s
Gemma 3 4B	88.7%	95.6%	60.9%	5.3 s / 8.4 s
Qwen3.5 4B	88.2%	95.6%	62.5%	5.2 s / 8.4 s
Gemma 4 E4B	–	–	–	5.6 s / 37 s

I picked Gemma 4 E2B because when it isn't sure, its suggestion is right far more often, so the shopkeeper taps Confirm instead of typing.

Then I tested it once, on orders I had locked away

Before tuning anything, I set aside 80 test orders and locked them; CI fails if they change. Each method ran on them exactly once:

Method	Handled with no review	No typing needed
Exact match	54.9%	54.9%
Fuzzy match	84.3%	84.3%
Model on every line	84.3%	92.2%
Hybrid (the app)	88.2%	92.2%

The model was needed on only 31 of the 80 lines, about 1.5 s each.

Watching the model be wrong, with Sentry

I traced an evaluation run in Sentry, one trace per order line, with steps for fuzzy matching, the model call and the safety rules. My favourite trace is the Red Label line.

Adha kg means half a kilo, so the 500 g pack. The model answered the 250 g pack, with status "ok", confident and wrong:

The safety rules didn't trust it. Both pack sizes fit the order's words equally well, so the line went to a human:

The model suggests; the code decides. The trace also shows every model call going to http://127.0.0.1:11434: the laptop itself, not a cloud. Across all 320 practice orders: 113 model calls, 640 tool calls, 58K tokens, $0.

Tracing lives only in the evaluation tool, runs only on synthetic data, and only when switched on. The shop app itself sends nothing anywhere.

CI keeps me honest

Every push runs 210 tests on GitHub Actions, checks that the locked test orders haven't changed by a single byte, and posts the no-model baselines to the run page.

What I Got Wrong

My first design asked the model for everything: product, quantity and unit. During development it was the worst design I measured, and on the final test it only tied plain fuzzy matching. That's why the model now picks only the product.
"1,500 bags" became 1 bag, and went green. The comma split aashirvaad atta 10 kg 1,500 bag into two lines. A wrong row, filled in on its own: the one thing the app must never do. Now Indian and Western digit groups (1,500, 1,00,000) are read as one number, and anything unclear like 1,5 gets a question.
"Remember" could learn the wrong size. "tata tea premium" was amber only because the order didn't say which size. Learning that name would have auto-accepted one size forever. Now only names the catalogue doesn't know can be learned, and a learned name means the product, never one pack size.
The model won near-ties for a silly reason. lays 10 wala 2 ctn names no flavour, but the model's pick, Classic Salted, led by 0.074, only because its alias was short. Now a model pick is accepted only if the order's own words put it ahead by at least 0.08, the same margin fuzzy matching needs. That was the last wrong row in development.
I tried a bigger model. Gemma 4 E4B needs about 6 GB; on 8 GB, only 2.5 GB fit on the GPU and the slowest line took 37 seconds. On a shop laptop, RAM is the limit, not disk.
I nearly trusted my friends' first replies. They were written by ChatGPT, not typed by hand. If I hadn't noticed that all four had the same shape, my "real-world" test would have been one more synthetic test (the full story is under My First User).

Why Does Open Innovation Matter?

The orders are the business. Customer names, what they buy, at what price: a shop won't paste that into someone else's cloud. With an open-weight model, nothing leaves the laptop. The app only listens on 127.0.0.1.
It costs ₹0 per order. No API bill growing with every WhatsApp message. That's what makes small-shop pricing possible.
It works when the internet doesn't. Market internet is unreliable; this runs fully offline, as the video shows.
I could test and choose. Because the weights are open and run locally, I could put five models through the same orders and pick the one that fits an 8 GB laptop.

My First User

Honestly, I don't have a paying user yet. No shopkeeper has used ParchiMatch. So I did the next best thing: I asked friends to type a restock order the way they'd really send it to a supplier.

The first replies were suspiciously perfect. Four messages, each exactly 17 lines, every item in the same order as my list, one a light rewording of another. My friends had asked ChatGPT. 😄 I threw them away and asked again, with six items and "please type it yourself."

Three real, messy messages came back, like this one:

bhai kal subh tk ye dal dena parle g 5wla 2 petti tata nmk 1 bori fotune tel pouch 1l 3 petti amul btar 100g 20 pis dairy milk 20rs 2 dabba or lifeboy 10 sabun 1 ptti bil sth bhej dena

I labelled the 11 order pieces, locked them, and scored them once:

0 wrong rows filled in, and 80% needed no typing.
One strict miss: fortune oil 1 ltr ke 1 carton went through without a question, though I had labelled it as worth asking (pouch or bottle?). Its row matched my label exactly, but by my own strict rule it counts, so I report it.
The app asked instead of guessing on every hard piece. For items joined with aur, though, its suggestion names only one product, so a busy operator could miss the second.

It's 11 pieces from 3 people: a signal, not proof.

What It Can't Do (Yet)

Items joined by aur, or sent with no separator, aren't split. The app asks about them, but its suggestion names only one product.
"Pouch" isn't a unit word yet. And Tata namak fits Tata Tea about as well as Tata Salt, so it asks.
Tested on synthetic shop data plus 11 real pieces, not on a real shop's catalogue yet.
It exports a CSV; it doesn't write into Tally or Busy directly.
Tested only on a MacBook Air M2 with 8 GB. Windows and Linux are untested.

The next step is one real shop and one week of real orders.

Prize Categories

Best Use of Gemma: Gemma 4 E2B (gemma4:e2b-it-qat via Ollama) is the model in the app, chosen by testing five models and confirmed once on locked test orders.
Best Use of Sentry Agent Tracing: the evaluation tool sends invoke_agent, chat and execute_tool spans for every order line. The traces above show a confidently wrong model answer being caught by the safety rules.
Best Use of GitHub Copilot: entered through the GitHub Actions route. CI runs the tests, the locked-test guard and the baselines on every push.

If you run a shop, or know someone who does: clone it, load your own catalogue as a CSV, and paste in yesterday's WhatsApp orders. It never needs the internet, and it will ask before it guesses.

Prep Buddy: an AI interview coach for my classmate that runs on his laptop with the Wi-Fi off

Bipul Chamoli — Fri, 02 Oct 2026 22:21:45 +0000

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

What I Built

Aman is my classmate. We're both in final-year B.Tech, and like everyone in our batch he's preparing for campus placements: SDE-1 roles, which means technical rounds on DSA, DBMS, Operating Systems, Networks and OOP, plus an HR round.

When I asked him how his prep was going, he wasn't sure. He was putting in the hours, but he couldn't tell which topics were actually weak. Nobody was asking him questions and telling him what he'd missed, so he kept revising the topics he was already comfortable with.

The usual answers didn't fit him either:

He practises late, around 11 PM, when nobody is free to give him a mock interview.
The hostel Wi-Fi is unreliable, and paid mock-interview platforms need a stable connection (and money).
Interview answers are personal. A "tell me about yourself" answer shouldn't have to go to someone else's server.

So I built Prep Buddy: a mock-interview coach that runs entirely on his laptop. It asks him a placement question, grades his typed answer against the points a real interviewer listens for, tells him what he missed, and remembers his weak topics so the next question goes after them.

₹0 to run · no API keys · no account · works with Wi-Fi off · his answers never leave his laptop

A practice session works like this:

Prep Buddy asks a question from a bank of 56 questions across 7 topics (DSA, CS fundamentals, DBMS, OS, CN, OOP, HR), reworded the way a friendly interviewer would ask it.
Aman types an answer and gets a score out of 10, what went well, what was missing, an outline of a strong answer and the follow-up question an interviewer would likely ask next.
If he missed something, the next question is picked to target that gap.
At the end, he gets a summary with his strongest topic, the one to work on next and 3 concrete next steps.

After a few sessions, the dashboard answers the question he couldn't: where should I spend my next ten minutes?

Demo

The Wi-Fi is off in this recording. Every question, grade and summary comes from Gemma running locally on my Apple M2 laptop with 8 GB of RAM.

There's no hosted link, on purpose. Hosting Prep Buddy on a server would break the one promise it makes: your answers stay on your laptop. The repo below runs on any 8 GB+ machine.

The badge in the top-right corner says AI ready only when the database is up, Ollama is running and both models are downloaded. If something is missing, it shows the exact command to fix it (for example ollama pull gemma3:4b) instead of an error page.

What I Measured

Machine: Apple M2, 8 GB

Chat model: Gemma 3 4B

Question bank: 56 questions across 7 topics

Step	Cold	Warm average
Next question	41.15 s	20.37 s
Grade answer	25.50 s	14.81 s
Session summary	23.81 s	15.08 s

For the golden-answer test, all 5 questions passed the required
Excellent > Average > Wrong ordering.

The prompt-injection test scored 2/10 and was classified as weak.

Code

bipul724 / prep-buddy

Prep Buddy

An offline, private mock-interview coach for campus placements, powered by Google Gemma running on your own laptop.

Built for Aman for the DEV Hacktoberfest Weekend Challenge: Build for a Friend.

₹0 to run · no API keys · works with Wi-Fi off · your answers never leave your laptop

▶️ Demo video: youtu.be/TgRr7m_U_FE

What it does

Asks you placement interview questions from a hand-written bank of 56 questions across 7 topics (DSA, CS fundamentals, DBMS, OS, CN, OOP, HR), in a friendly interviewer tone.
Grades your typed answer: a score out of 10, strengths, gaps, an outline of a strong answer and a follow-up question.
Remembers your weak topics and picks the next question to target them (EmbeddingGemma + pgvector).
Ends each session with a short summary and 3 concrete next steps.

Dashboard	Session summary

Why local, open-source AI

Every model call goes to Ollama…

View on GitHub

The setup is three steps: start Ollama and pull the two models, run docker compose up for the database, then npm run dev. The README has the full commands. The repo also has the PRD, the architecture, the API reference, the AI design notes and the test results in docs/. The code is MIT-licensed.

How I Built It

The open-source AI at the core:

Piece	What it does in Prep Buddy
Gemma 3 4B (open-weight, 3.3 GB) via Ollama	Rewords questions, grades answers, writes the session summary
EmbeddingGemma (622 MB, 768-dim vectors) via Ollama	Turns questions and "what you missed" into vectors
Mastra (open-source TypeScript agent framework)	Three agents: interviewer, evaluator, coach
PostgreSQL + pgvector	Stores progress and does the "find a question about this gap" search

The rest of the stack is Next.js 16, React 19, TypeScript, Tailwind, Prisma 7 and Zod.

      Browser (localhost:3000)
        | fetch JSON
        v
 Next.js API routes --> services: pick next question, grade, summarise
                              |                         |
                     Mastra agents                ollama JS client
          (interviewer, evaluator, coach)          (embeddings)
                              |                         |
                              v                         v
                  Ollama on localhost:11434: gemma3:4b + embeddinggemma

 PostgreSQL 17 + pgvector (Docker, 127.0.0.1): profiles, attempts, topic stats, question vectors

Every arrow stays on the laptop. There is no cloud service in this diagram.

Here are the decisions that made a 4B model good enough to trust with someone's interview prep.

1. One job and one JSON schema per call, with no tool calling

Small models get unreliable when you ask them to do several things at once, and Gemma 3 isn't listed as tool-capable on Ollama. So each agent does exactly one thing and must return JSON that matches a Zod schema. Mastra passes the schema to Ollama as its format field, so the decoding itself is constrained to valid JSON. Then I validate it again with Zod anyway:

const res = await agent.generate([{ role: "user", content: prompt }], {
  structuredOutput: { schema, errorStrategy: "strict" },
  providerOptions: { ollama: { options: { num_predict: 800 } } },
  abortSignal: AbortSignal.timeout(60_000),
});
return schema.parse(res.object); // never show half-broken JSON to the user

A failed call is retried once, and then the user sees a clear error. If Ollama isn't running, the API returns 503 MODEL_UNAVAILABLE with the command to start it, so the UI never just crashes.

2. Facts come from the question bank, not the model

The 56 questions were written for this app, not copied from LeetCode or GFG, and each one has 2 to 6 key points (for example, normalization → reduces redundancy, avoids insert/update/delete anomalies, 1NF/2NF/3NF, trade-off: more joins). The model never invents a question. It only rewords one, and the evaluator grades against those key points as a rubric. That's how a 4B model can grade like an interviewer without making up what the "right" answer is.

3. Targeting weak spots with EmbeddingGemma and pgvector

When the evaluator returns gaps like "didn't mention update anomalies", I embed those gaps and ask Postgres for the closest unasked question in the same topic:

SELECT id, prompt, embedding <=> $gaps::vector AS distance
FROM "Question"
WHERE topic = $topic AND id <> ALL($alreadyAsked)
ORDER BY distance
LIMIT 1;

On top of that, there's a plain difficulty ladder. A topic starts at EASY, moves to MEDIUM once his average is 7 or higher, and to HARD at 8.5. In "Auto" mode, each session starts with his weakest focus topic. The vectors and the progress data live in the same database, so I didn't need a separate vector store.

4. Not trusting the model with things code can do

Arithmetic: the overall session score is computed in code. The model's number is overwritten.
Consistency: Gemma sometimes said "strong" next to a score of 5, so the UI derives the verdict from the score.
Double-clicks: every submit sends an Idempotency-Key. The attempt insert and the topic-average update run in one database transaction, so an answer can't be graded twice.

Every number here was measured on the laptop itself, not on a cloud GPU. To be honest about it: "next question" misses my 15-second target, because rewording costs an extra model call. Setting REPHRASE_QUESTIONS=false skips it. On a laptop with less RAM, CHAT_MODEL=gemma3:1b is a one-line switch.

Things that went wrong (and what I did about them)

The model got stuck in a loop. Sometimes Gemma repeated 0} 0} 0}… until the context filled up, and a request hung for minutes. I tried capping maxOutputTokens, and it did nothing. Reading the provider's source showed why: that setting is sent as a field Ollama's /api/chat ignores. Ollama's own num_predict works, so I used that, plus a 60-second timeout.
The interviewer answered its own questions. When asked to reword a question, the model would sometimes answer it instead. Now a reworded question is only used if it still ends with ?. Otherwise Prep Buddy shows the original wording.
Prompt injection. Answers are wrapped in <answer> tags and treated as data. While tuning, I found that Gemma 3 4B followed injected text more when my rules came after the answer, so the answer now goes last. I also had to tell it to penalise answers that use the right words but state the facts wrong.

Why Does Open Innovation Matter?

For Aman, it's the difference between a tool he can use and one he can't.

What Aman needs	With Gemma on his laptop	With a typical closed AI API
Practise at 11 PM on hostel Wi-Fi	Works fully offline once the models are downloaded	Needs a working connection for every answer
Practise every night as a student	₹0 per answer, so 50 questions cost nothing	Paid per token, or a subscription
Keep his answers private	Nothing leaves the laptop: no account, no API key	Every answer goes to a third-party server
Run on his machine	Swap `gemma3:4b` ↔ `gemma3:1b` with one env var	Whatever model the vendor serves

There are two less obvious ways open mattered.

I could read the code when things broke. Both of my worst bugs (the token loop and the ignored output cap) were solved by reading the source of the Ollama provider and checking what was actually being sent. With a closed API, all I'd have seen was a request that took four minutes.

The privacy promise shaped the product. I planned voice input, then dropped it. The browser's speech recognition in Chrome sends audio to a server, and that would have broken the one promise this app makes.

To be fair to closed models: a large hosted model would give richer feedback, and it would give it faster. But Aman can't use that one in the hostel at 11 PM, for free, without sending his answers to someone else's server. A 4B model he can use every night beats a better model he won't.

Handing it to Aman

I gave it to Aman and sat with him while he did a practice session. His verdict:

"What I liked about Prep Buddy was that after answering the questions, I was provided with instant feedback and it helped me to identify my weak areas. It helped me to know about my strengths and weaknesses prior to the interview."

Finding his weak areas before the interview is the part I built it for. He was already putting in the hours. What he didn't have was someone telling him where to put them, and now his laptop does that, with the Wi-Fi off.

Prize Categories

Best Use of Gemma: Gemma is the product. Gemma 3 4B runs all three agents (rewording, grading against a rubric, coaching), and EmbeddingGemma powers the weak-spot targeting. Both run locally through Ollama, on an 8 GB laptop.
Best Use of Mastra: the interviewer, evaluator and coach are Mastra agents. Mastra's structuredOutput with Zod schemas is how every model call returns validated, schema-constrained JSON from a local model.

If you're preparing for placements too, clone it, add your own questions to data/questions.json, and practise without needing Wi-Fi.