Sagar Maurya

Posted on Oct 19

How I Built Parchi: Turning Messy WhatsApp Orders into a Clean Order Sheet with Gemma

#devchallenge #hf26challenge

Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle Submission 💸

This is a submission for the Hacktoberfest Week 2 Challenge: Side Hustle

What I Built

A parchi is the slip of paper an order gets written on. Parchi is a small web app that does that job for sellers who take orders on WhatsApp.

The home page. The handwritten sheet on the right is the kind of order list a seller starts with.

Think of a home baker, a sweet shop or a tiffin service. Orders arrive as chat messages, usually in a mix of Hindi and English, in no fixed format:

bhaiya kal subah 5 kg laddoo chahiye, Sharma ji ke ghar, 10 baje tak
Priya here, 2 dozen cupcakes for saturday pls, no nuts
Amit 4 tiffin kal se, 1 me sirf roti sabzi
cake chahiye

At the end of the day the seller scrolls back through the chat, works out who ordered what, adds up the bill by hand, and decides how much to cook for tomorrow. One missed message or one wrong sum costs money or a customer.

You paste the messages into Parchi, one per line. It gives you back:

an order table with customer, items, delivery day and a total in rupees,
a Check flag on every order that is unclear, so you look at it instead of trusting a guess,
a prep list that adds up what to make for each day, with a button to copy it for WhatsApp,
an editable price list and a CSV download.

The person who would pay for this is the small seller who is still doing it with a notebook and a calculator. I have not charged anyone yet, so I won't pretend there is revenue. What I can say is that the problem is real, the tools that exist for it tend to be built for bigger shops, and the whole thing runs on a laptop the seller already owns.

The order table. Each row shows the customer, items, delivery day and total, with a Ready or Check status. Click a row to see the original message.

The prep list. Quantities from every order are added up per day, ready to copy into WhatsApp.

The price list. Edit it, press Save prices, and the totals update.

Demo

The sample orders in the demo are made up. They are not real customers.

Code

mauryasagar / parchi

Turn messy WhatsApp orders (Hinglish too) into a clean order sheet, totals and a prep list for small food sellers. Runs locally with Gemma and Ollama.

🗐 Parchi

Turn messy WhatsApp orders into a clean order sheet, totals and a prep list.

Built for home bakers, sweet shops and tiffin services. Runs fully on your own laptop with an open-weight Gemma model.

The problem

A small food seller in India takes most of their orders on WhatsApp. The messages look like this:

bhaiya kal subah 5 kg laddoo chahiye, Sharma ji ke ghar, 10 baje tak
Priya here, 2 dozen cupcakes for saturday pls, no nuts
Amit 4 tiffin kal se, 1 me sirf roti sabzi
cake chahiye

They are written in a mix of Hindi and English, with no fixed format, and they pile up in a chat. At the end of the day the seller has…

View on GitHub

How I Built It

The one rule: the AI only reads. Plain code does the math.

A language model is good at understanding "didi 1 kilo kaju katli aur 500 gm barfi, parso shaam tak". It is not something I want adding up a customer's bill. So the work is split in two.

WhatsApp messages
      |
      v
 Flask server  -->  core.py  -->  Gemma 4 (local, via Ollama)
                       ^                  |
              prices.csv                  | JSON: customer, items,
                       |                  | quantity, unit, day, notes
                       v                  v
        plain Python: unit conversion, totals,
        Check flags, prep list grouped by day
                       |
                       v
          browser page: orders, prep list, prices

Read. For each message, core.py asks a local Gemma model for JSON only: customer, items (name, quantity, unit), delivery_day and notes. The prompt says to use null for anything not in the message and not to guess.
Price. Plain Python matches each item to prices.csv, converts units (500 gm becomes 0.5 kg, a dozen becomes 12 pieces when the price is per piece) and calculates the line total.
Flag. An order gets a Check stamp when it has no quantity, an item that is not in the price list, a unit that does not match the price, no items at all, an unclear delivery day, or a date range such as "monday se friday". Date ranges are kept out of the totals and the prep list on purpose, because "how many days?" is a question for the seller.
Group. Orders are grouped by delivery day and quantities of the same item are added up for the prep list.
Remember. The model's answer for each message is saved in a local cache, so reading the same message again is instant.

The stack is deliberately small: Python and Flask on the back, one HTML file and one CSS file on the front, no build step, and Ollama serving the model on localhost.

Which Gemma. I ran the same 15 made-up orders through gemma4:e2b and gemma4:e4b on a CPU-only Windows laptop with 16 GB of RAM. E2B took about 2 minutes and invented or dropped items on 3 of the 15 messages. E4B took about 4 minutes and was clearly cleaner, so it is the default. An invented item quietly makes a bill wrong, which is exactly why the totals are plain code and unclear orders are flagged.

What a real run looks like. With E4B, all 15 sample orders were read. 9 came out Ready and 6 were marked Check. The Check ones are the ones a person should see: two date ranges, an item that is not in the price list ("mithai ka dabba"), a message with no quantity ("cake chahiye"), an item where the model returned no quantity, and one order in "dabba" where the price is per kg.

Why Does Open Innovation Matter?

Three things here only work because the model is open and runs locally.

Privacy. An order message contains a name, an address and sometimes a phone number. With a local model none of that leaves the seller's machine. No account, no API key, no upload.
Cost. There is no per-message fee. A closed API charges for every message, which is a hard sell to someone running a margin of a few rupees per laddoo.
Choice of size. Because the weights are open, I could pull both E2B and E4B, run them side by side on the same orders, and pick the smaller model that was good enough. That comparison is what showed me where the small model fails, and it shaped the rule that the model never does arithmetic.

It also works with no internet, which matters more than it sounds for a shop on a patchy connection.

Prize Categories

Best Use of Gemma. Gemma 4 does the one job that needs real language understanding: reading a messy Hinglish order like "didi 1 kilo kaju katli aur 500 gm barfi, parso shaam tak" and turning it into JSON (customer, items, quantity, unit, delivery day, notes). I told it to return null for anything missing instead of guessing.

I used the open weights in two ways. I ran both gemma4:e2b and gemma4:e4b on a CPU-only Windows laptop with 16 GB of RAM, with no GPU and no cloud. E2B finished 15 orders in about 2 minutes but invented or dropped items on 3 of them. E4B took about 4 minutes and was clearly cleaner, so it is the default. That comparison is also why Gemma never touches the money. It reads, and plain Python adds up the bill.

A small seller can run this on the laptop they already have, and customer names and addresses never leave it.