DEV Community: Rahul Tapase

PrepMate: Practice Interviews While Gemma 4 Does the Prep Work

Rahul Tapase — Sun, 25 Oct 2026 19:09:41 +0000

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

What I Built

PrepMate is a mock interviewer that runs on your own laptop. You drop in your resume PDF, paste the job description, pick Technical, HR or Managerial, and then you just talk. Gemma 4 reads your background, asks you tailored questions out loud, listens to your spoken answers, and when you end the session it hands you a scorecard: a communication score and a technical (or behavioral) score for every answer, a written comment on each one, an overall score, and a short list of things to work on.

Interview prep is the task everyone puts off. Doing it properly means hunting for question lists that match your role, rehearsing answers alone in your head with no idea whether they're any good, or convincing a friend to play interviewer for an hour and then give you honest feedback. PrepMate does all three jobs. The only effort left for you is showing up and speaking.

The lazy parts it handles for you:

No question hunting. Questions are generated from your resume, target role, company and job description, so a frontend intern and a backend engineer get different interviews.
No typing. Questions are read aloud and your answers are captured by voice.
No self-grading. Every answer is scored and commented on.
No tuning. After five completed sessions of the same type, the questions get harder on their own.
No bookkeeping. Every session lands on a dashboard with search, filters and the full feedback, so you can see whether you're improving without keeping notes.

I'm a student heading into interview season, so I'm the first lazy person this was built for.

Demo

The home page. One button and you're in.

Setting up a session: fill in the role, paste the job description, and upload your resume as a PDF. That's all the typing you'll do.

Code

rahultapase / Prep-mate

🎯 PrepMate - AI Mock Interview Platform

Practice interviews with a local AI interviewer, answer by voice, and get scored feedback on every session.

📖 About

PrepMate runs a full mock interview on your own machine. It reads your resume and the job description, asks tailored questions out loud, records your spoken answers, and then scores each answer with written feedback. The AI model (Gemma 4) runs locally through Ollama, and all data is stored in a local SQLite file.

✨ Features

🤖 AI interviewer - Questions generated by Gemma 4 from your resume, target role, company and job description
📄 PDF resume upload - Text is extracted in the browser and can be edited before the interview; pasting text also works
🎙️ Voice answers - Questions are read aloud and answers are captured with speech-to-text
📚 Interview types - Technical, HR and Managerial
⚡ Scored feedback - Per-question communication…

View on GitHub

How I Built It

Architecture

Browser (React + TypeScript + Vite)
   │  /api/*
   ▼
Express on 127.0.0.1:3001
   ├── auth  → SQLite users + sessions
   ├── data  → SQLite profiles, interviews, ratings
   └── ai    → Ollama at 127.0.0.1:11434 (gemma4:e2b)

The server only listens on 127.0.0.1, and the resume PDF never leaves the browser: pdf.js extracts the text client-side, and only that text goes into the prompt.

Talking to Gemma

The whole AI layer is one call to Ollama's chat API:

const res = await fetch(`${url}/api/chat`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  signal: controller.signal,
  body: JSON.stringify({
    model,                       // gemma4:e2b by default
    messages: [{ role: 'user', content: prompt }],
    stream: false,
    think: false,                // skip the reasoning trace, it only adds latency here
    ...(format ? { format } : {}), // JSON schema for feedback
    options: { num_ctx: numCtx },  // 16384
  }),
});

Three settings did most of the work:

think: false. A list of interview questions doesn't need a reasoning trace, and skipping it cuts the wait noticeably on a laptop.
num_ctx: 16384. A resume (up to 10k characters) plus a job description (up to 8k) plus the instructions doesn't fit in Ollama's default context window, and the prompt would get truncated. Raising it keeps the whole resume in view.
Schema-constrained feedback. The dashboard reads exact fields, so the feedback has to be valid JSON every time. App sends a JSON schema as Ollama's format, and Gemma's output is constrained to that shape. HR and Behavioral interviews get a behavioral score; Technical and Managerial get a technical score:

const perQuestion = softSkillsInterview
  ? { question: str, answer: str, communicationScore: scoreInt, fluencyComment: str, behavioralComment: str }
  : { question: str, answer: str, communicationScore: scoreInt, technicalScore: scoreInt, fluencyComment: str, techComment: str };

Small model, clear rules

gemma4:e2b is small enough to run on an ordinary laptop, so the prompts are explicit about format: one question per line, no headings, no labels, nothing else. A tolerant parser then keeps lines that end in a question mark, so a stray intro sentence from the model doesn't end up as "question 1".

Being honest about the hardware

Before an interview starts, a system check calls /api/health, which asks Ollama whether it's running and whether the model is installed. If either is missing, the Start button stays locked and the page shows the exact command to fix it (ollama serve or ollama pull gemma4:e2b).

Local generation is slower than a cloud API. On gemma4:e2b, questions take roughly 20 to 60 seconds and feedback 10 to 30 seconds, depending on the machine. The app says so up front instead of pretending otherwise. For a week themed on sloths, a short wait in exchange for keeping everything on your own disk felt like a fair trade.

Why Does Open Innovation Matter?

A mock interview is personal data. Your resume carries your phone number, email, college and grades, and your answers include things like "tell me about a time you failed." The resume text, questions, answers and scores live in one SQLite file on your disk, and the API isn't reachable from outside your machine.

Where the open approach worked better than the closed one:

It costs nothing per interview. Practice only works if you do it a lot. With a local model there's no quota or bill to ration, so a tenth mock interview costs the same as the first: nothing.
No API key. Setup is one ollama pull, and nothing expires.
Swap the model with one line. OLLAMA_MODEL=gemma4:e4b gives better questions and feedback if your machine has the memory for it. Nothing else changes.
Control over the output. Constraining Gemma to a JSON schema through Ollama made feedback dependable enough to build a dashboard on.

One honest caveat: speech-to-text still uses the browser's Web Speech API, and Chrome sends that audio to Google's speech service. So PrepMate isn't fully offline yet. The AI, the data and your resume are local, but live transcription needs a connection. Moving transcription to a local Whisper model is the next step to close that gap.

Prize Categories

Best Use of Gemma: Gemma 4 (gemma4:e2b) runs locally through Ollama and generates every interview question, the follow-up rounds, and all scored feedback, with schema-constrained JSON output for the scorecards.

Thanks for reading. If you try it, I'd like to hear how it scored you.

Shopkeepers won't retype their udhaar khata. KhataLens reads it with Gemma 4, locally

Rahul Tapase — Sun, 18 Oct 2026 09:23:05 +0000

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

What I Built

Walk into almost any kirana shop and you'll find a notebook next to the till: the udhaar khata. A regular customer takes five kilo atta today and pays on Saturday, so the shopkeeper writes it down: date, name, item, amount. When money comes back, he writes "jama".

The notebook works until he needs a total. Knowing who owes what means re-adding pages of handwriting, with the same customer scattered across many pages. Then comes the harder part: asking a neighbour for money without it getting awkward. So dues slip.

Free ledger apps like Khatabook and OkCredit exist, but they ask the shopkeeper to type every entry into a phone, on top of the notebook he already keeps. KhataLens starts from the notebook instead:

Photograph the pages. One page or a whole book. Gemma 4 reads every handwritten line into an editable ledger that sits next to the photo.
Check it. Fix any misread in place. Corrected rows are tagged, and balances update as you type.
Get the hisaab. The same customer across pages adds up into one balance (udhaar minus jama), sorted by who owes most, with the total to collect always visible.
Send a polite reminder. Gemma drafts a short, respectful Hinglish message with the customer's name, the exact ₹ amount, the shop name and, optionally, the shop's UPI ID. The shopkeeper copies it or opens WhatsApp, picks the contact and taps send himself.
Export. Download the ledger and the balances as a CSV for Excel.

Everything runs on the shop's own computer. Gemma 4 E2B runs locally in Ollama, so the photos, names and amounts never leave it.

Who would pay, and for what. The customer is the shopkeeper. He wouldn't be paying for a ledger, because those are free. He'd be paying to not change his habit: he keeps writing in the notebook, and once a week he photographs the new pages and gets every balance plus a ready-to-send reminder for each customer. If the reminders bring back one forgotten ₹500 a month, a ₹99 monthly fee pays for itself. That price only works because reading a page costs nothing: there's no per-image API bill that grows with every page he photographs.

To be upfront: no shopkeeper has used it yet. Everything below was tested on three khata pages I handwrote myself, with made-up names.

Demo

KhataLens needs Ollama on the same machine, by design, so there's no hosted demo. Setup is a model pull and two npm commands, all in the README.

1. Three handwritten pages, one ledger. The photo stays next to the table, and every row is tagged with the page it came from (P1, P2, P3), so the shopkeeper can always go back to the paper:

2. The hisaab, and a reminder drafted by Gemma. After all three pages, Ramesh owes ₹240, Pooja ₹150, Imran ₹110 and Arjun ₹40, while Kavita and Sunita are settled: ₹540 to collect (₹1,700 udhaar minus ₹1,160 jama). Pick a customer and a tone, and Gemma writes the message:

Code

rahultapase / KhataLens

KhataLens

Photograph a page of a handwritten udhaar khata. Gemma 4 reads it on your laptop, turns it into an editable ledger, totals what each customer owes, and drafts a polite Hinglish payment reminder you can copy or open in WhatsApp. Nothing is sent automatically and nothing leaves the laptop.

Built for Best Use of Gemma 4 at Hacktoberfest 2026 Mumbai.

The problem

Small shops across India run on credit. A regular customer takes atta today and pays at the end of the week, and the shopkeeper writes it in a paper udhaar notebook: date, name, item, amount and "jama" when money comes back. Working out who owes how much means re-adding pages of handwriting, and asking for money is awkward, so dues slip.

Existing ledger apps expect the shopkeeper to retype everything. KhataLens starts from the notebook he already keeps.

What it does

Photos in. Take or drop one…

View on GitHub

Vite and TypeScript with no runtime dependencies, plain HTML and CSS, and Gemma 4 E2B through Ollama. There is no backend.

How I Built It

One small open model, two jobs. KhataLens uses gemma4:e2b (about 4.6B parameters, Q4_K_M) through Ollama's /api/chat. The browser reaches Ollama through Vite's dev proxy, so there's no server, no API key and no CORS setup. On my laptop's 4 GB RTX 2050, a page takes about 6 to 9 seconds once the model is loaded.

1. Reading the page: vision with a JSON schema. The photo is downscaled in the browser to a 1280 px JPEG and sent with a JSON schema in Ollama's format field, so Gemma has to answer as structured data. Thinking is off and the temperature is 0.1. The system prompt explains khata conventions: a name with an amount is udhaar unless the line says jama, paid, diya or received; read numbers literally and never calculate; one entry per written line, never invent rows; set unclear fields to null; count the lines you can't read.

2. The bug that shaped the schema. My first schema asked for customer, amount, kind, date and item directly. On my handwritten pages, Gemma read two short payment lines like "Pooja jama 100" as udhaar. That's the worst kind of error for a khata: it adds ₹100 to Pooja's balance instead of taking it off.

The fix was to make Gemma copy the whole line before splitting it:

properties: {
  // Exact transcription first: the model reads the whole line before splitting it,
  // and the app can check it for payment words itself.
  line: { type: "string" },
  customer: { type: "string" },
  amount: { type: "number" },
  kind: { type: "string", enum: ["udhaar", "jama"] },
  date: { type: ["string", "null"] },
  item: { type: ["string", "null"] },
},

Then code applies the khata rule to each line instead of trusting the model's label: a payment word (jama, paid, diya, received...) in the copied line means jama, and a real item of goods means udhaar.

Version	Result on 3 handwritten pages (24 lines)
First schema	2 short jama lines read as udhaar
Copy-the-line-first schema + code rule	every name, amount, date and udhaar/jama correct, in each of 3 runs

3. Guardrails around the model. Invalid JSON gets one retry; after that, Gemma's raw answer is shown instead of a blank error. The model is warmed up as soon as the app opens, and a status pill shows "Gemma loading" or "Gemma 4 ready". The editable table is the core of the design, not a fallback: handwriting is messy, so the photo and the rows are always side by side. If the same page is added twice, the app asks before counting it again. For that it stores only a SHA-256 fingerprint of each resized photo, never the photo.

4. Reminders: Gemma writes the words, code checks the facts. Gemma gets the customer, the amount, the shop name and a tone (polite, friendly, or firm but respectful), and writes at most 60 words of Roman-script Hinglish. The prompt rules out threats, shaming, legal words and any mention of other customers. Before a draft is shown, code checks that it contains the name, the exact amount and the shop name, and no Devanagari. If not, it retries once, then falls back to a fixed template. The UPI line is added by code, never by the model, so it's always exact. If a later page or an edit changes the balance, the draft is marked outdated, so an old amount isn't sent by mistake.

5. Small security details. Model output goes into the page as text, never as HTML. The CSV export writes any cell starting with =, +, - or @ as text, so a customer name can't turn into a spreadsheet formula. Ollama stays on localhost.

How the work was split. I built it solo with an AI coding agent (Kiro), phase by phase from a written plan: the Gemma core first, tested on a handwritten photo before any UI existed, then the ledger, reminders, a design pass and multi-page reading. I made the calls on scope, the khata rules and the tests, and the agent did much of the typing.

Why Does Open Innovation Matter?

A khata is other people's financial data. It records which neighbour bought what and who hasn't paid. That isn't the shopkeeper's data to upload to a server he doesn't control, and "we send your customers' dues to an AI company" is not a pitch a kirana owner will accept. With an open-weight model running in Ollama, the photo, the names and the amounts stay on his computer.

Zero cost per page is what makes the price work. A hosted vision API charges for every image, so the bill would grow with every page he photographs and every reminder he drafts. Local inference makes that cost zero. A flat monthly price doesn't get eaten by usage, and the shopkeeper never sees a surprise bill.

It doesn't depend on the shop's connection. After ollama pull gemma4:e2b, reading pages and writing reminders work offline. Only the final WhatsApp step needs the internet.

I could shape the whole pipeline, not just the prompt. JSON-schema output, thinking off for speed, low temperature, and the copy-the-line-first schema that fixed the jama bug. Because the model is small, one model covers both jobs, reading handwriting and writing Hinglish, on a laptop with a 4 GB GPU.

Where closed would be better, to be honest. A large hosted model would probably read messier handwriting better. KhataLens makes up for that by keeping the photo and the editable row side by side, so a misread costs a two-second fix instead of a wrong balance.

Limitations

It was tested on three pages (24 lines) in my own handwriting, with made-up names. Real khatas are messier: cramped lines, crossed-out entries, running totals.
It handles Roman-script Hinglish with English numerals only. Devanagari and Marathi notebooks aren't supported yet.
Customers are matched by name (trimmed, case-insensitive), so "Ramesh" and "Rameshbhai" become two customers.
It needs a computer with Ollama, and many shopkeepers only have a phone.
No shopkeeper has used it yet.

What's next

Put it in front of a real shopkeeper with a real khata, and ask whether he'd pay. After that: Devanagari pages, a phone version (E2B is the smallest Gemma 4 size, so it's worth testing on a phone), voice entry ("Ramesh, atta paanch kilo, do sau pachaas"), and sending through the WhatsApp Business API with the shopkeeper's approval for every message.

Prize Categories

Best Use of Gemma: Gemma 4 E2B does both jobs locally: vision with structured output to read handwritten khata pages, and writing Hinglish payment reminders.

Log Off: One Real Place. One Small Activity. Local Gemma.

Rahul Tapase — Mon, 12 Oct 2026 06:14:00 +0000

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

What I Built

At 4:00 PM in Kharghar, I gave a local model a deceptively small job: stop offering me choices and choose one real place I could walk to and return from in 30 minutes. The map pipeline found CIDCO Park seven minutes south, the timing code kept the outing inside daylight, and the interface reduced everything to one ticket. That test became Log Off.

Log Off turns four quick choices into one reason to close the laptop. You choose your mood, how much time you have, your energy, and whether you are alone. It then:

finds real nearby outdoor places from OpenStreetMap;
checks walking time, current weather, sunrise, and sunset;
asks a local Gemma 4 model for one small activity at a place that actually fits; and
shows one ticket with where to go, what to do, when to leave, and when to be back.

The model does not decide distances or invent the schedule. Code owns those facts. The goal is to make the screen the shortest part of the experience.

Demo

Log Off runs locally on a laptop, so there is no hosted demo. Setup and run instructions are in the README. Here is the complete screen flow:

1. Pick what you need from the break. Four compact choices give the planner enough context without turning the break into another questionnaire.

2. Take one ticket and leave the screen. The result gives one real place, one activity, and the leave-by and back-by times calculated by code.

Code

rahultapase / log-off

Log Off

Log Off turns a few preferences into one short reason to leave the screen. Pick a mood, the time available, your energy, and whether you are alone. The app finds a real nearby place, works out a safe walking window around daylight and weather, and asks a local Gemma 4 model for one small activity to do there.

The result is a single outing ticket with where to go, when to leave, when to be back, and a task that needs no phone, purchase, or equipment.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

Screenshots

How it works

Log Off keeps facts and generation separate:

Find facts. A typed area or browser location is rounded to three decimal places before the app requests nearby places from OpenStreetMap and daylight and weather data from Open-Meteo.
Build a shortlist. Python code calculates walking time and…

View on GitHub

FastAPI, TypeScript, Vite, local Gemma 4 through Ollama, and 104 backend tests.

Repository: github.com/rahultapase/log-off

How I Built It

Log Off has three deliberate layers: facts, generation, and validation.

1. Facts before AI. A FastAPI backend uses OpenStreetMap for geocoding and nearby places, then Open-Meteo for weather, sunrise, and sunset. Python code rounds outbound coordinates, calculates walking time and compass direction, merges duplicate map entries, and filters out anything that cannot fit the selected time budget.

That produces a numbered shortlist of real places. It also decides whether the outing can happen now or should move to just after sunrise. Gemma never calculates any of this.

2. A local Gemma task writer. Gemma 4 E2B runs locally through Ollama. It receives mood, energy, company, weather, and the numbered shortlist, but no coordinates. Its job is narrow: select one candidate ID and return a short, equipment-free activity as structured JSON.

I found that the model was much more useful after code supplied a task style for each mood and energy combination. The first prompt often returned variations of "relax in the park." The final prompt asks for a concrete, finishable observation, investigation, movement, or social task.

3. A factual guardrail. Every model response passes through a validator that checks:

valid JSON and schema;
a place ID from the supplied shortlist;
an activity duration that fits after the round-trip walk;
invented place or street names;
forbidden distances and clock times; and
extra safety constraints for darkness and rain.

A rejected response gets one repair attempt. If Ollama is unavailable or both attempts fail, a built-in deterministic activity keeps the ticket usable. The explanation visible to the user is also generated from code facts, not from Gemma's free-text reasoning.

4. I measured it. For the main evaluation, I ran 24 combinations of mood, time, company, and energy at 4:00 PM:

Result with Gemma 4 E2B	Measured value
Valid on the first attempt	23 of 24
Fixed on the single retry	1 of 24
Deterministic fallback used	0 of 24
Invented-place runs	0 of 24
Median model-call latency	2.8 seconds
Maximum model-call latency	3.2 seconds

The most useful failure was not a hallucination. For a social, with-others, low-energy request, Gemma suggested: "Start a simple card game like Uno." It passed the factual validator but needed equipment, despite the prompt. The validator can prove that an answer fits known facts; it cannot yet prove that the idea is good. That distinction is now an explicit limitation instead of a hidden one.

5. I swapped the model. With the same 12 preference sets, gemma3:1b passed 0 of 12 answers on the first attempt. Eleven were repaired and one fell back safely. Gemma 4 was much more reliable, but the open setup let me measure that difference inside the real application.

6. I kept the final screen quiet. The browser interface is TypeScript and Vite. It uses a daylight arc, accessible controls, visible focus states, reduced-motion support, and one final screen designed to be left behind.

Why Does Open Innovation Matter?

The model does not need my location. Gemma runs on my laptop through Ollama, so no location is sent to a model provider, no model API key is needed, and inference has no per-request fee. I can inspect the full prompt, constrain its role, keep evaluation results locally, and replace the model without redesigning the app.

I could test model sizes on the real task. The Gemma 3 and Gemma 4 comparison used the same planner, validator, preference sets, and hardware. I could choose based on measured reliability instead of a general benchmark or pricing page.

Open data keeps generation grounded. OpenStreetMap provides inspectable place IDs and geometry, while Open-Meteo provides weather and daylight data under an open licence. Together they let the model write around facts instead of pretending to know the user's surroundings.

Open does not automatically mean offline. Place and weather lookups still need the internet. It does mean I can draw a clear privacy boundary: rounded coordinates go to open-data services, while Gemma stays local and never sees them. It also means the failure handling is mine to test, explain, and improve.

Limitations

The 24-run evaluation is a focused application test, not a general model benchmark.
The validator checks facts and safety rules, not taste. The Uno suggestion passed.
Weather describes current conditions even when an after-dark outing moves to tomorrow morning.
Place and weather lookups need internet access, even though model inference is local.

What's next

Take Log Off on a real outing, add an equipment-language validator rule, use forecast data for next-morning plans, and compare more small local models on the same evaluation set.

Prize Categories

Best Use of Gemma: Gemma 4 E2B writes the activity locally, and Gemma 3 1B provides the measured comparison.

My mom runs tuition from a paper register. I built her one that reads Hinglish, runs offline, and never does the maths itself

Rahul Tapase — Mon, 05 Oct 2026 06:54:30 +0000

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

What I Built

My mom teaches home tuition. About 25 kids come to her, from class 1 to class 10.

Everything lives in a paper register. Attendance goes in one column, fees in another, and in the margins there are notes like "paid half, rest next week". Parents message her on WhatsApp: "Ma'am 1000 bhej diya, baaki next week". At the end of the month she goes back through the register and the WhatsApp chats and adds up, by hand, who has paid for which month and who still owes. Then comes the part she likes least: reminding parents about fees without sounding rude.

So I built Tuition Register. She types a line the way she'd write it in the register:

riya nahi aayi, aman ne 1500 diye oct ke, baaki 500 next week

and it becomes three entries: Riya absent today, ₹1,500 from Aman for October, and ₹500 promised by next Monday. From those it keeps a month-by-month dues list and drafts a polite reminder she can copy into WhatsApp.

The one rule I built everything around: Gemma reads, code counts. The model copies words out of her line. It never computes a balance, a date or an amount. Code checks everything the model says, and anything it can't confirm goes to a Confirm tray for one tap instead of being saved quietly.

To be upfront: Mom hasn't used it yet. Everything below was tested on synthetic lines I wrote in her style. Sitting with her at the next month-end is the real test.

TL;DR

60 synthetic Hinglish register lines, 79 facts, measured with Wi-Fi off
Gemma 4 E2B on its own got 94% of facts right (precision and recall)
Without the checker it would have silently saved 7 wrong entries out of 79. With it: 2, and 7 facts went to the Confirm tray instead
3.3 s per line (p50) on a laptop with a 4 GB RTX 2050
₹0 to run, no API key, nothing leaves the house

Demo

It runs locally on a laptop, so there's no live link. Setup takes about three commands and is in the README. Here's the flow:

1. She writes a line. Code shows what the model picked out of it. Green means checked, amber means "please look". The Neha card is amber because there are two students called Neha:

2. The Confirm tray. It asks which Neha. Nothing is saved until she picks one:

3. Dues for the month. Who still owes, who's paid, and open promises:

4. Tap a student for their ledger and a reminder. The model wrote the wording. Code put in "₹800" and "October":

Code

rahultapase / hacktoberfest-weekend-challenge

Tuition Register

A tuition fee and attendance register my mom can write to like a notebook. She types a line the way she'd write it in her paper register (riya nahi aayi, aman ne 1500 diye oct ke, baaki 500 next week). A local Gemma model (Ollama) copies out the names, amounts and months as exact spans. Code turns them into numbers and dates, checks everything (rules V1 to V8), and does all the money maths. Anything it can't confirm goes to a Confirm tray instead of being saved. Runs fully offline.

Built Oct 5, 2026 for the DEV Hacktoberfest Weekend Challenge: Build for a Friend.

All data in this repo is synthetic. The 18-student roster and the 60 test lines were written by me in the style of a home-tuition register. No real children's names or payments. Mom hasn't used it yet.

Write	Confirm tray	Dues

…

View on GitHub

Python (FastAPI + SQLite), one HTML page with vanilla JS, 137 tests, and the eval set and results committed in eval/.

How I Built It

Stack. Gemma 4 E2B running in Ollama on my laptop, FastAPI, SQLite, and a single HTML page with vanilla JS and no build step. Every piece is small and offline. The page is mobile-first so it works from her phone over home Wi-Fi.

1. The model copies, it doesn't convert. Ollama's format option takes a JSON schema, so the output is always valid JSON. The schema only asks for spans exactly as written:

{"type": "payment", "student_text": "aman", "amount_text": "1500", "month_text": "oct", "date_text": null}

Then plain Python takes over. 1.5k, 1,500, 15 sau and dedh hazaar all become 1500. pichle mahine becomes 2026-09. next week becomes a date. kal means both "yesterday" and "tomorrow" in Hindi, so code reads it as the past for a payment and the future for a promise. Nicknames like "Riyu" and "Amu" are matched against the roster with rapidfuzz.

Because the model only returns spans, every claim it makes can be checked against what she actually typed. The app even shows her line back with those words highlighted.

2. The checker (V1 to V8). Every extracted fact runs through these rules:

Rule	Check
V1	Every span actually appears in her line (catches made-up values)
V2 / V3	The amount parses, and it isn't more than 6× that student's fee
V4	The name matches exactly one student, clearly ahead of the next best
V5 / V6	The month or date resolves, and required fields are present
V7	Coverage: every student named in the line appears in some entry
V8	Not already saved today

V7 is my favourite. Most checkers only look at what the model produced, but this one looks for what it left out. If she writes "mohit, arjun aur shreya nahi aaye" and the model returns only Mohit, she gets a card saying "You mentioned Arjun. Nothing saved for them."

3. All the money maths is in code. A payment goes to the month she named. Without a month, it goes to the oldest unpaid month, and anything extra carries forward as advance. One payment can cover two months ("sep oct dono ke"). Promises are tracked, but they never change a balance.

4. Reminders: the model writes the tone, code writes the numbers. Gemma writes a template like Namaste ji, {name} ki {month} ki fees ₹{amount} baaki hai… in Hinglish, English or Hindi, in a gentle, normal or firm-but-polite tone. Code rejects any template with a digit, a missing placeholder or the wrong language, and falls back to a built-in one. On the first try, E2B wrote "Hi [Parent's Name]…" in English when I asked for Hinglish, so the validator now checks for leftover brackets and for the language too.

5. I measured it. I wrote 60 synthetic lines in her style: single and multi-student attendance, payments in words ("aath sau"), partial payments with promises, WhatsApp messages from parents, typos ("kavya n 1500 diy"), English lines, chit-chat with nothing to save, and a few traps. I labelled them by hand from the rules, not by running the model. The few-shot examples in the prompt use different names, and a test enforces that. I ran it with Wi-Fi off, and the script records that the internet was unreachable.

Model	Fact precision	Fact recall	Silent errors, no checker	Silent errors, with checker	Sent to Confirm tray	p50 latency
Gemma 4 E2B (default)	94%	94%	7 of 79	2	7 facts (9%)	3.3 s
Gemma 3 1B	56%	52%	34 of 73	4	42 facts (58%) + 7 "missed?"	3.0 s

Some things the checker stopped:

rahul ne 1000 diye: there's no Rahul in the roster. A plain closest-name lookup would have credited ₹1,000 to Aman. V4 asked "New student?" instead.
aman ne 15000 diye: probably a typo for 1500. V3 flagged it as unusual instead of clearing ten months of fees.
neha absent: two students are called Neha. It asked which one.

And the 2 it didn't catch, because honesty matters more here than a clean table:

Ma'am Ishaan kal nahi aayega ("won't come tomorrow"). Code reads kal as yesterday for attendance, so the absence landed on the wrong day.
rohan ne 1200 jama kiye is mahine ke. The model dropped "is mahine ke" (this month), so the payment went to the oldest unpaid month instead of October. Rohan's total is still right, but the month is wrong.

6. Two Gemmas side by side. Gemma 3 1B is a bit faster, but it often copied the whole line into the name field, mixed up payments and attendance, and dropped 38 facts. The checker still kept its silent errors down to 4, but at the cost of sending more than half of everything to the tray, and that's not something Mom would put up with. E2B is the default.

7. How it was built. I worked with an AI coding agent (Kiro) through a spec I wrote: the rules, the schema, the ledger rules and the eval design. I made the calls on scope, rules and tests, and the agent did a lot of the typing.

Why Does Open Innovation Matter?

These are children's names and their parents' payments. They aren't mine or my mom's to upload to someone else's server. With an open-weight model running in Ollama, nothing leaves the laptop. I didn't just assume that: the eval ran with Wi-Fi off, and the results file records it.

It costs ₹0 to run, for good. No API key, no subscription, no per-call bill. That matters for a home tuition business.

I could choose the model to fit the machine. The laptop has a 4 GB GPU. Because the weights are open, I could try a 1B model and the newer E2B on the same 60 lines, with the same checker on the same hardware, and pick based on numbers rather than a pricing page.

I could shape the output itself. JSON-schema output, temperature 0, thinking turned off for speed, and a prompt tuned for Hinglish register notes. The checker trusts the model only as far as it can verify, which is easier when you control the whole pipeline.

With a closed API, every one of these would have been harder or impossible: uploading kids' data, paying per line, needing internet at the tuition table, and no way to compare model sizes on my own machine.

Limitations

The test set is small and synthetic: 60 lines I wrote in her style. It's a sanity check, not a benchmark, and her real writing will be messier.
kal (yesterday or tomorrow) is still a guess for attendance. She can fix it in the tray or the day's list.
Typing Hindi in Devanagari script hasn't been tested yet.
LAN mode for her phone has only a simple shared PIN. It's for a home network only.
No voice input yet.
Mom hasn't used it.

What's next

Hand it to Mom and test it on her real month-end. Then: voice notes through a local Whisper, Devanagari input, and a one-page monthly summary.

Prize Categories

Best Use of Gemma: Gemma 4 E2B is the default model and the core of the app. Gemma 3 1B is the comparison.