DEV Community: Abhinav Garg

BusyMobile: GST bookkeeping for small Indian shops, with an AI that never leaves the shop

Abhinav Garg — Sun, 18 Oct 2026 08:39:35 +0000

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

What I Built

My father runs a small cement trading business. Like millions of Indian shopkeepers, he keeps GST books, and every month he does the same tedious job: going through the bank statement line by line.

UPI/DR/412345678901/RAMESH KUMAR/YESB/ramesh@ybl/Payment        -5,000.00
NEFT CR-HDFC0000123-MODERN HARDWARE STORE-INV 12              +26,880.00
ACH D- BAJAJ FINANCE LTD-P400XXXX                               -8,450.00

For each line he works out who paid whom, whether it was a customer, a supplier, a loan EMI or the electricity bill, and types it in as a voucher. Then he does the same for every supplier's paper bill.

BusyMobile is an offline-first Android/iOS app for GST bookkeeping: invoices with CGST/SGST/IGST, party ledgers, stock, GSTR-1/3B summaries, and PDF invoices to share on WhatsApp. It has an AI assistant built on an open-weight model that runs on a laptop in the shop:

Bank import. Pick the bank's CSV. Rules settle the obvious lines (ATM, cash deposit, charges, interest, EMIs). The model reads each UPI/NEFT/IMPS narration and works out the counterparty and the kind of transaction. Confident lines post in one tap.
Type or speak an entry in Hinglish. "kal Bangar Cement ko 1.5 lakh cheque se payment kiya" becomes a ₹1,50,000 bank payment to Bangar Cement, dated yesterday, as a draft to confirm.
Scan a supplier's bill. A photo of a GST bill becomes a purchase invoice draft with bill number, date, items, HSN codes and GST rates, matched to existing stock.

Who would pay for it: small traders, kirana and hardware shops, and the accountants who keep books for twenty of them. They already pay for desktop software like BUSY or Tally, and they pay with hours every month for data entry. They won't upload their bank statements to a foreign AI service, and they won't accept a per-call bill they can't predict. A flat monthly fee for an app that runs on hardware they already own is an easy sell.

Demo

busymobile-demo.mp4 - Google Drive

drive.google.com

The whole video is real: a Pixel 6 emulator talking to gemma3:4b in Ollama on my laptop over the local network. Waits for the model are sped up and labelled with the real time.

AI Quick Entry	Bank Import — Categorised	Local AI Configuration

src/services/ai.js: the local model client (Ollama /api/chat with a JSON schema, or any OpenAI-compatible server), plus the rule layer around it
src/utils/bankParser.js: CSV parsing for HDFC, SBI, ICICI, Axis, Kotak and others, and the rules for deterministic lines
src/utils/ledger.js: balances computed from entries, so they can't drift
tests/: npm test runs 22 logic tests, and npm run test:live runs the real prompts against your own model server

How I Built It

Stack: React Native + Expo on the phone, and Ollama serving Google's open-weight gemma3:4b on any laptop on the shop Wi-Fi. One 3.3 GB model handles both text and bill photos. The app also speaks the OpenAI-compatible API, so llama.cpp's server or LM Studio work too.

ollama pull gemma3:4b
OLLAMA_HOST=0.0.0.0 ollama serve      # then: Settings → Local AI → http://<laptop-ip>:11434

My first version didn't work. I sent the 4B model 8 bank lines at a time and asked for an array back. It misaligned the answers: Suresh's name ended up on the Bajaj EMI line, and two lines came back empty. It also recorded "UPI se mile" as cash, invented a party called "Bank", and in one run read "1.5 lakh" as ₹1.5.

The fix was not a bigger model. It was a different split of work:

Rules decide anything that must never be wrong. ATM is a cash withdrawal. "UPI", "cheque" or "NEFT" means the bank, not cash. "1.5 lakh" is 150000, and "kal" means yesterday. "Bank" is never a party. An invalid GSTIN is never saved: the model once dropped a character from one, and validation caught it.
The model handles only the fuzzy part: who is this, and what kind of transaction is it? It sees one line at a time, with a strict JSON schema where every field is required (Ollama's structured outputs).
Names are matched against the shopkeeper's own party list with strict token matching, so "Ambuja Cements Ltd" maps to the existing "Ambuja Cement Ltd" ledger instead of creating a duplicate.
Every AI result is a draft. Nothing is posted until a human taps it, and each line shows its confidence.

After that, all 10 lines of my test statement were correct, and it ran 2× faster (53 s vs 116 s on CPU). Small prompts with one job each beat one big prompt for a 4B model.

Measured on my laptop CPU (16 GB RAM, no GPU): about 5–10 s per bank line, ~20 s for a typed note, and 35–95 s for a bill photo. That's slow next to a cloud API, but this job runs once a month, and it's far faster than typing.

While building it I also fixed the bookkeeping underneath. Balances are now computed from the vouchers instead of being mutated in place. That fixed a sign bug, and it means editing or deleting an entry can't leave a stale balance. Without this, the AI would only have posted wrong numbers faster.

Why Does Open Innovation Matter?

1. The data can't leave the shop. A bank statement shows every customer, supplier, loan and payment of the business, and GSTINs and party ledgers are just as sensitive. Most traders I know would never upload that to a US AI API, and they shouldn't have to. With a local model, the privacy promise is simple and easy to check: unplug the router and it still works. The app shows where each request goes ("Processed on 192.168.1.x — never sent to the cloud").

2. The unit economics work. A shop's statement has hundreds of lines a month, plus bills and daily entries. With an open-weight model on a laptop the shop already owns, the marginal cost per line is zero. I can charge a flat, small monthly fee without a busy customer wiping out my margin. A closed API would turn every bank line into a cost I'd have to pass on.

3. I could build for a niche general tools handle badly. Indian bank narrations, Hinglish ("jama kiya", "nikale", "kal"), lakh and crore amounts, and GST rules are a narrow domain. Owning the whole stack let me wrap the model in rules exactly where it was weak and run it with a schema I control. When a better small model comes out, I can test it with npm run test:live in minutes.

4. No lock-in. Swapping gemma3:4b for Qwen, Llama or next year's small model is a settings change, not a migration. Nobody can change my pricing, deprecate my model or read my customers' books.

Where closed would have won, honestly: a frontier API would be more accurate on messy narrations out of the box, and much faster. For this customer, though, "private, free per use, works offline, good enough with guardrails" beats "a bit smarter, sends your books abroad, bills per call".

I built this with Claude Code as a pair programmer. The most useful part of the session was running the real prompts against the local model, seeing the batched version fail, and redesigning around one line per call plus rules.

Prize Categories

Best Use of Gemma: gemma3:4b runs locally through Ollama and does all three AI jobs (bank narrations, Hinglish notes and bill-photo reading) on a laptop CPU, with structured JSON outputs.

Week-1

Abhinav Garg — Sat, 10 Oct 2026 17:57:12 +0000

Hacktoberfest Submission: WildGuide Local

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

What I Built

WildGuide Local is a privacy-first, offline AI companion designed to turn your smartphone or laptop into a field guide for the great outdoors. It helps users identify plants and animals and provides regional ecological advice without requiring an internet connection.

The goal is to lower the barrier to nature exploration by providing instant, local knowledge, while explicitly encouraging users to "put the screen away and observe" after getting their answers. It's built for hikers, gardeners, and nature enthusiasts who want the power of AI without the tether of a data plan or the privacy concerns of cloud-based APIs.

How I Built It

WildGuide Local is built entirely on an open-source, local-first stack:

Local Inference: Powered by Ollama, allowing the app to run heavy models on consumer hardware.
Vision Model: Uses llava for image recognition and species identification.
Reasoning Model: Uses Llama 3 for generating ecological advice and interpreting local data.
RAG (Retrieval-Augmented Generation): Implemented using LangChain and ChromaDB. This allows users to ingest their own regional ecological data (frost dates, local laws, native species lists) into a local vector store, making the AI an expert on their specific backyard.
Frontend: A clean, tabbed interface built with Streamlit.

Why Does Open Innovation Matter?

Open innovation is the heartbeat of WildGuide Local. By using open-weight models and local inference, we achieve three things that a closed API couldn't:

True Offline Capability: In the deep woods, there is no 5G. A closed API is useless in the very environment where this tool is needed most.
Absolute Privacy: Nature exploration is personal. By keeping images and queries on-device, users don't have to trade their privacy for knowledge.
Community Customization: Because the RAG pipeline is open, the community can share "Regional Knowledge Packs" (JSON/Text files) that others can drop into their local instance to immediately make their guide an expert on a specific National Park or biome.

Prize Categories

Local AI / Edge Computing
Environmental Impact / Nature
Open Source Contribution

Offline DSA Interviewer: The LLM Talks, the Code Decides

Abhinav Garg — Mon, 05 Oct 2026 04:36:11 +0000

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

What I Built

An offline mock DSA interviewer. You pick a problem, think out loud while you code in the browser, and it behaves like a real interviewer: it asks for your approach before you code, gives graduated hints when you're stuck, runs your solution against hidden tests, asks for complexity, then throws edge cases at you.

I built it for *, who *[one honest sentence: what they're preparing for and what's been hard for them, e.g. nobody to practice with, can't afford paid mock interviews, or doesn't want their voice and half-formed code sent to someone's server]. It gives them unlimited practice, free, with nothing leaving their laptop.

Demo

demo.mp4 - Google Drive

drive.google.com

It's local-first, so the demo is a screen recording of a full interview: clarify, approach, a failing run, a hint, a passing run, complexity, edge cases, report.

How I Built It

Qwen3-8B via Ollama (open weights) is the interviewer's voice. It returns schema-constrained JSON: one action from the list the current state allows, plus a short message.
A Go state machine owns the flow: clarify → approach → code → complexity → follow-up. The model can't skip phases, and the code phase only ends when every test passes.
Correctness comes from a sandboxed test runner, not the LLM. Small local models are unreliable judges. Hints and edge cases come from a curated question bank, and the final report contains only facts (tests passed, runs, hints used).
Graceful degradation: if the model is unavailable, a deterministic fallback keeps the interview running.
Known limits: the subprocess sandbox isn't a security boundary, it's Python-only, and input is text-only for now. Next up: tree-sitter code hints, whisper.cpp voice, Monaco vendored offline, and scripted fake-candidate regression tests.

Why Does Open Innovation Matter?

A practice interview exposes your half-formed thinking, your mistakes and your voice. With open weights running locally, all of that stays on the machine. It works without internet, costs nothing per session, and anyone can swap the model or edit the interviewer's rules. A closed API would mean per-call costs, rate limits, and sending someone's struggle to a third party. For a friend practicing under pressure, that trade matters.