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.

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.

DEV Community

JobTalk: Talk the Job, Get the Quote