DEV Community: Anushka Gupte

JobTalk: Talk the Job, Get the Quote

Anushka Gupte — Mon, 19 Oct 2026 06:21:55 +0000

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

What I Built

JobTalk turns a tradesperson’s spoken description of a job into a formatted, itemized quote. It runs entirely on their own laptop, with no cloud and no accounts.

The buyer I had in mind is a self-employed plumber, electrician, or AC technician in India. They finish a job, then spend an evening typing up a quote, or they send a scribbled WhatsApp message. Items get forgotten and quotes look unprofessional. With JobTalk they say something like “Geyser ka thermostat badla, do ghante ka kaam, paanch sau rupaye labour” and get an itemized quote in rupees, ready to print, save as PDF, or share on WhatsApp.

Some details came from thinking about who actually uses it:

Amounts use Indian digit grouping (₹1,23,456.00), with optional GST and CGST/SGST split and a round-off line.
Setup is optional. There’s no signup, and many small tradespeople have no business name or logo, so the quote header falls back gracefully.
It’s built for being wrong. The raw transcript stays next to the editable line items, and the app flags anything it isn’t sure about.

Demo

The demo shows: speak a job, watch the transcript appear, watch line items stream in, fix one line, and export.

Code

Anushka-Gupte / JobTalk

JobTalk - Talk the Job, Get the Quote

JobTalk

Dictate a job, get a quote. A plumber or electrician describes the work out loud on-site JobTalk turns it into a formatted, itemized quote. It runs fully offline on open models (Whisper for speech, a small local LLM for extraction).

Why open models

Offline: works in basements and rural sites with no signal.
Private: customer names, addresses and prices never leave the device.
Cheap: no per-quote API fees, so a flat low price stays profitable.
Customizable: your own price list, swappable models, fine-tunable per trade.

Quick start

pip install -e ".[web,audio]"   # one-time setup
python run.py                   # checks Ollama, starts server, opens browser

Open http://localhost:5000 — or on a phone on the same Wi-Fi, http://<laptop-ip>:5000.

The first run downloads qwen2.5:1.5b (~1 GB) if it isn't already pulled. All settings (business name, tax rate, model, port) live in config.yaml.

CLI (no browser needed)

ollama pull qwen2.5:1.5b

…

View on GitHub

How I Built It

The pipeline has three parts, all open and all local:

faster-whisper transcribes the audio on CPU.
qwen2.5:1.5b, served by Ollama, reads the transcript and returns structured JSON (customer, address, line items). Output is constrained with a JSON schema, and the model streams items to the UI as they’re generated.
Plain Python does everything that involves money.

The design rule that mattered most is that the model extracts and the code calculates. Small models are unreliable at arithmetic, so totals, GST, and round-off live in a Decimal-based pricing module, with a randomized test checking that subtotal + tax + round_off == total. The model is also told never to invent prices. A missing price stays empty, is filled only from the user’s own price list, and blocks export until confirmed. A deterministic check also flags any price that doesn’t appear in the transcript.

What I measured (CPU only, no GPU; 26 hand-written transcripts, with an 11-transcript held-out set of about 48 line items):

Prompt changes alone moved item recall from 51% to 87% on my first fixtures, with no fine-tuning.
On the held-out set, the 1.5B model found about 85% of billable items (runs ranged from 83% to 87.5%) and scored about 92% overall. The 3B model scored about the same but ran roughly 35% slower. A 7B model took about 150 s per quote on CPU, which is too slow to be useful.
A warm quote takes about 22 seconds on a plain laptop CPU, and the first one about 32 s.
I tried putting items first in the output schema. It cut time to the first line from about 20 s to about 5.6 s but dropped accuracy by 4.4 points, so I rejected it. A missed line is lost revenue.

What went wrong, because it’s useful:

It misses roughly 1 in 7 billable items, so I built around that. My automatic “items may be missing” warning is also weak: it caught 9 of 17 real misses and raised 6 false alarms. Because of that, the UI never implies the quote is complete. It highlights number phrases in the transcript that match no line, keeps removed or old items visible (greyed out, with a Restore button) instead of deleting them, and keeps every line editable.
My test suite passed while the audio path was broken. A newer PyAV removed an argument that faster-whisper still passes, and every test used text or fake transcription, so nothing caught it until I ran real audio.
My test set is small and I tuned post-processing rules while looking at it. Treat the numbers above as a rough guide, not a benchmark.

Why Does Open Innovation Matter?

Each of these is something a closed API would have made hard for this product:

It works where the job is. Basements, crawl spaces, and rural sites often have no signal. A cloud API fails exactly there. After the one-time model download, JobTalk needs no connection.
Customer data stays on the device. Names, addresses, and prices never reach a server, so there are no accounts, no database, and nothing to breach. That’s also why I deliberately skipped signup.
The business model works. There’s no per-quote API fee, so a flat low price (I’m considering something like ₹299 a month or ₹999 once) leaves a margin. With a metered API, every quote would cost money and the price would have to cover it.
I could change what mattered. I swapped models and compared them on my own transcripts, changed the prompt and the output schema, added Indian number words and rupee handling, and put a deterministic price check around the model. Those are the kind of changes you can’t make to a hosted model you don’t control.
I could be honest about its limits. Because I ran the model myself, I could measure its misses and design the product around them.

A closed frontier model would likely be more accurate on messy Hinglish. I didn’t test that comparison and don’t claim it. What the open model gave me was privacy, offline use, and a cost that suits a very low-margin customer. For this buyer, those mattered more.

EdgeMate: a local AI coding interviewer, built for a friend

Anushka Gupte — Mon, 05 Oct 2026 05:40:23 +0000

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

What I Built

A few weeks ago my friend spent weeks preparing for a software engineering interview. They worked really hard, and then didn't get it. The thing that hurt most wasn't the "no". It was that nobody told them what went wrong. Interview rejections come with no feedback, so you're left replaying a 45-minute performance in your head.

I built EdgeMate for them: a private, offline mock interviewer that runs on their laptop. It runs a real interview (understand the problem, discuss an approach, code, debug, discuss complexity, get a debrief) and it never makes them feel stupid for being stuck.

Three things I cared about:

It's gentle by default. The default "Friendly" persona opens with what you did well, gives hints freely, and never says "wrong".
It never spoils the answer. The model is never shown the reference solution, so it can't leak it.
It stays on their machine. Rejection is a vulnerable moment. The code they write and the things they say while stuck shouldn't sit on someone else's server.

Demo

Code

Anushka-Gupte / EdgeMate

Local Open-Source AI Coding Interviewer

EdgeMate

Local Open-Source AI Coding Interviewer

"The code runner checks whether the solution works. The open-source AI handles the human part of the interview."

Demo

flowchart TD
    subgraph Frontend["Frontend Layer (Dark-First Developer Theme)"]
        UI["Web SPA / UI (FastAPI & Uvicorn / Gradio)\n• Progressive Stage Panels\n• Live Python Editor & Examples Drawer\n• Problem Catalog & Progress Dashboard"]
    end
    subgraph API["Backend & Orchestration Layer"]
        ROUTER["REST API Routes (/api/sessions/*)"]
        STATE["Session State Machine (InterviewSession)\n• State: UNDERSTANDING ➔ APPROACH ➔ REVIEW ➔ CODING ➔ TESTING ➔ DEBUGGING ➔ COMPLEXITY ➔ DEBRIEF\n• Real-Time Attempt Tracking & Timestamps"]
        AGENT["Interviewer Agent (InterviewerAgent)\n• Context-Bounded Prompt Builder\n• Active Persona Adaptation\n• Socratic Guidance (Zero Solution Leaks)"]
    end
    subgraph LocalAI["Local Open-Source LLM (Ollama)"]
        OLLAMA["Ollama Engine (Local CPU/GPU Inference)\n• Default: qwen2.5-coder:3b (Q4_K_M)\n• Alternatives: llama3.2:3b, mistral:7b\n• 100% Offline & Private"]
    end

    subgraph Execution["Deterministic Execution Engine (Zero LLM Hallucinations)"]
        KB_LOADER["KB Loader (interview-kb/loader.py)\n• 119 Problems • 20 DSA Patterns\n• Pre-Materialized Hidden Tests & Large Generators"]
        RUNNER["Test

…

View on GitHub

How I Built It

The one design rule: code checks, the model talks.

My first instinct was to ask an LLM "is this code correct?". That's exactly where small models are worst. They can't reliably trace pointer loops, big inputs, or off-by-one bugs, and they love to dump the full solution. So I split the job:

Candidate code ──► deterministic subprocess runner ──► pass/fail + a failure tag
                                                              │
Candidate chat ◄── local LLM (Ollama) ◄── pre-written follow-up question for that tag

Correctness is deterministic. Code runs in an isolated subprocess with a timeout against hidden tests. The LLM only receives tests_passed, tests_total and a failing_tag such as empty, duplicates or large.
The model only phrases the question. Every problem in my knowledge base has pre-written follow-ups mapped to failure tags, so the model turns "failed on duplicates" into a kind, Socratic question.
A small model is enough. Because the model never judges code, a 3B model on an 8GB laptop does the job. I use Qwen2.5-Coder 3B via Ollama by default.

The interview itself is a state machine with 7 stages: understanding → approach → approach review → coding → Socratic debugging → complexity → 4-pillar debrief. The editor and the optimal Big-O stay hidden until the right stage, like a real interview. There's also a 3-level hint ladder (question → nudge → concrete invariant).

The knowledge base is 119 problems across 20 patterns, stored as plain JSON. Each has a reference solution, a brute-force solution, tagged tests, hints, and planted "common bug" solutions with the follow-up question for each. I checked it two ways:

The reference solution must agree with an independent brute-force solution on hand-written tests and 300 random inputs per problem.
In the real sandbox, every planted bug must fail at least one test carrying the tag it claims.

That second check caught my own mistakes: a "bug" that turned out to be a valid alternative algorithm, and bugs my tests couldn't actually catch. I fixed the tests and re-verified.

Stack: Python, FastAPI, SQLite for session history and progress, Ollama for local inference, plain files for personas and problems. Personas (Friendly / Standard / Silent) are markdown files with word budgets.

Why Does Open Innovation Matter?

1. Privacy where it matters most.
Someone processing a rejection is typing "I froze on this question" and their half-working code into a tool. With a hosted API, all of that goes to a server they don't control. With Ollama, nothing leaves the laptop. There's no account, no telemetry, and it works with no internet.

2. It runs on the hardware my friend actually has.
They have an 8GB laptop, so I couldn't pick a big model. The architecture makes that fine: deterministic tools do the judging and a 3B open model does the talking.

3. I can change how the interviewer behaves.
The interviewer's personality is a markdown file. I can make it warmer, stricter, or nearly silent for stress practice, by editing a text file. The problem bank is the same: when my friend gets asked something new next time, they add one JSON entry. No retraining, no subscription.

4. I could compare models instead of trusting one.
EdgeMate has a benchmark endpoint that compares two local models on latency and on whether they respect the tone and word limits.

5. Zero cost to practise.
Fifty practice rounds cost the same as one: nothing. For someone job hunting, that matters.

Where open beat closed, and where it didn't. A hosted frontier model would write a smoother conversation. But it would also cost money per session, send a vulnerable person's code and feelings to a third party, and tempt me to let it judge correctness, which is the part models get wrong. Open weights plus deterministic tools gave me something more trustworthy, more private, and cheaper for this one person.