This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle
What I Built
Parchi turns a day of messy WhatsApp food orders into a prep sheet, per-customer bills and ready-to-send replies, running entirely on the seller's own laptop.
The person it's for is a solo food seller, such as a home baker or tiffin seller, who takes orders as chat messages. Messages like "ek choco cake dedh kilo ka" and "wait actually make it 1 kilo" pile up all day. Every night the seller re-reads them and works out what to make, how many, and who owes what. That's slow, easy to get wrong, and the chats contain customers' names and addresses.
With Parchi, the seller pastes the day's chat (or uploads a WhatsApp export) and gets:
- a prep sheet with the total quantity of each item to make,
- a bill for each customer,
- a confirmation reply to copy straight into WhatsApp,
- a CSV export.
Anything the AI can't match to the menu, such as an off-menu "pineapple cake", is highlighted as Needs review so the seller fixes it with one click instead of silently losing an order.
Would someone pay for it? I think a free tier plus a small monthly fee is plausible for sellers who handle many chats a day, but that's a hypothesis. No real seller has tested it yet, and I haven't validated a price.
Demo
It runs locally, so the demo is a short screen recording: load the menu, paste the chat, click Process orders, fix a "Needs review" item, then show the prep sheet, a bill and a copied reply.
Code
Parchi
Parchi turns a day of messy WhatsApp food orders into a prep sheet, per-customer bills and ready-to-send replies, running fully on your own laptop with an open-weight model.
Project status
Working prototype. Evaluated on synthetic data only. Real-seller validation pending.
Quick start
ollama pull gemma4:e2b
pip install -r requirements.txt
.\start.ps1
then open http://localhost:8000
The Problem
A home baker or tiffin seller gets orders as chat messages like "ek choco cake dedh kilo ka" and re-reads and totals them by hand every night. This manual process is time-consuming, repetitive, and prone to costly calculation and counting mistakes.
How It Works
- Parse (regex): WhatsApp export text is parsed into structured messages, skipping system lines and normalizing directional control marks, non-standard spaces, and newlines.
- Group by Customer: Messages are grouped chronologically by sender.
- Extract with Gemma 4: Each customer's message history and the seller's menu are sent to…
How I Built It
Model: Gemma 4 E2B, run locally through Ollama. I also tested Gemma 4 E4B.
Pipeline:
WhatsApp export -> regex parser -> group by customer
-> Gemma extracts items + quantities as JSON (checked against the seller's menu)
-> code validates + post-processes -> code computes every total
The design rule that makes it dependable: the model only extracts, and code does all the maths. Totals, prep sheets and bills are never generated by the AI. Each extracted item has to map to a menu ID, otherwise it is flagged "Needs review".
Stack: Python, FastAPI, Ollama's local API (JSON-schema output, temperature 0, one retry on invalid JSON), and a single HTML page. There are 17 automated tests.
What I measured (10 synthetic customers, 23 expected items; the sample chat and labels are in the repo):
| Run | Precision | Recall | Qty accuracy | Avg s/customer |
|---|---|---|---|---|
| E2B, original prompt | 90.9% | 87.0% | 95.2% | cold start, not comparable |
| E2B, revised prompt | 95.5% | 91.3% | 100% | 6.1 |
| E2B, revised prompt + code post-processing | 100% | 91.3% | 100% | 7.1 |
| E4B, original prompt | 90.9% | 87.0% | 95.2% | 13.2 |
| E4B, revised prompt | 100% | 78.3% | 100% | 15.5 |
What I learned, including what failed:
- The bigger E4B model gave no accuracy gain and was about twice as slow, so E2B is the default. E4B got more precise by dropping items, which is the worse failure for a seller because a dropped item is a lost order.
- The model kept ignoring two prompt rules: "paav kilo = 0.25" and "when a customer corrects a quantity, keep only the final one". Fixing them in code worked better than rewording the prompt. A correction-merge bug that sometimes gave 6.5 kg of chocolate cake instead of 6.0 kg is now stable in 5 of 5 repeated runs.
- Still failing: requests phrased as questions for off-menu items, such as "ek pasta bhi banana hai kya?", are not reliably extracted by E2B. The seller catches them when reviewing.
- Caveat: I wrote the prompt rules and post-processing while looking at this same synthetic chat, so these scores are optimistic and say nothing certain about real-world accuracy. Ten customers is also a small sample.
Why Does Open Innovation Matter?
For this customer, three things matter:
- Privacy. Order chats contain names, phone numbers and addresses. With a local open-weight model, none of it leaves the seller's laptop.
- Cost. Because inference runs locally, there are no per-message API fees; the only cost is the seller's own laptop and electricity. For a tiny-margin business with hundreds of messages a week, that matters.
- Control. I could swap between E2B and E4B, measure them on my own test set, and choose the smaller one. A closed API wouldn't have let me do that.
To be honest about the trade-off, a large closed model would probably understand messy Hinglish better. Parchi trades some accuracy for privacy and zero running cost, and the review step is there to catch the mistakes.
Model license: Google released Gemma 4 under Apache 2.0, and the code is MIT. Check the official model card for the exact variant you use.
Prize Categories
- Best Use of Gemma: the whole product runs on Gemma 4 locally through Ollama, with E2B and E4B compared on a labelled test set.
Top comments (0)