Hisab App — bookkeeping that reads a handwritten mandi slip
A working prototype for the Indian kirana shopkeeper's oldest problem: the bahi-khata.
Context
Every Indian kirana shop still runs on two books: a purchase register kept by whoever's least busy that week, and a khata — a credit ledger — for the regulars who pay "next Tuesday, bhaiya." Both are usually handwritten. Both are why the shop owner's accountant charges a premium every GST filing season, reconciling stacks of paper bills against a return that's already overdue. There is no shortage of apps trying to fix this — Vyapar, Khatabook, OkCredit, myBillBook, Zoho Books all sell into the same shelf. That crowding was the first thing I had to reckon with before writing a line of a build prompt: if I was going to spend time on this, it couldn't be "another invoicing app with a nicer UI." It had to attack the one step every competitor still leaves to the shopkeeper — turning a stack of paper into a ledger in the first place.
The product decision that mattered
The obvious build is a manual entry app: shopkeeper types in supplier, amount, GST rate, done. Every incumbent in this category has that screen. I rejected it, because it doesn't remove the actual cost — a semi-literate or time-starved shopkeeper still has to sit down and become a data-entry clerk every evening, which is exactly the behavior that makes the paper register win by default. So the core of Hisab App isn't the ledger screen, it's the intake: point a phone camera at a supplier's invoice, mandi slip, or even a handwritten chit, and let the app extract supplier, GST number, line items, and tax split on its own. The harder call was what to do when the model isn't sure. I deliberately didn't ship a black-box "trust the AI" flow — every captured bill carries a confidence score, and anything under a threshold lands in a "Review & Verify" queue instead of posting straight to the ledger, with duplicate-bill detection sitting alongside it. That's a slower, less impressive demo than "scan and forget," but it's the difference between a toy and something a shop owner would actually let touch their GST filing — one wrong auto-posted credit note is enough to lose that trust permanently.
The second decision was language. Every competitor I looked at defaults to English with a Hindi toggle bolted on. I built the interface language-first instead — eleven languages including Hinglish, Gujarati, Marathi, Tamil, Telugu, Bengali, Punjabi — because the shop owner this is for is not the shop owner's college-going son who's fluent in app-English; it's the person actually standing behind the counter.
The third: GST in India isn't one flow, it's three. A shop can be on Regular scheme (full input tax credit), Composition (flat 1%, no ITC), or exempt under the ₹40L threshold — and the tax logic (CGST+SGST vs IGST) changes depending on whether the sale crosses a state line. I built the tax engine to ask which scheme a shop is on and compute accordingly, rather than assuming every user is a full Regular-scheme filer the way a lot of "GST billing" apps quietly do. That's a decision most vibe-coded finance demos skip because it's invisible in a screenshot — it only shows up when the numbers are actually right.
What it does today
A shop owner can log purchases by photo, run sales through a POS-style "New Sale" flow, track customer credit (khata) with per-customer balances and a one-tap payment reminder, and see a monthly Profit & Revenue view that nets output GST against input tax credit to show what's actually payable to the government — not just what came in and went out. Cash-vs-credit sales are split automatically, and the whole financial summary is exportable to WhatsApp, because that's the channel this shop owner already uses to talk to their accountant.
What I'd need to prove next
This is a prototype, not a shipped product — the OCR is simulated against realistic Indian invoice formats rather than trained on a live document pipeline, and there's no real payments or filing integration yet. The open question I'd want to test with actual shopkeepers: does a confidence-scored review queue actually get used, or does it get rubber-stamped the way most "please review" UIs do in practice? That's a behavioral question no amount of solo building answers — it's the next thing I'd want real usage data on.
What this shows about how I work
I didn't start from "what can Claude Code build me quickly." I started from where the existing category was leaving money on the table — the capture step, not the ledger step — and built the parts that are boring to demo but load-bearing for trust: confidence thresholds, scheme-aware tax logic, a language list that matches who's actually behind the counter. That's the same instinct I'd bring to any product decision: build the invisible thing that makes the visible thing trustworthy.
Try it
Built solo with Claude Code. View the live prototype →