How two kirana marts run on one grocery OS
Indian kirana software dies in the gap between a demo and a Tuesday evening queue. The Kirana Point is not a concept. Two marts run on it. I built the platform end-to-end at World Creator Ventures: one API, three clients.
One API on purpose
Admin/POS (30+ employees), customer app (100+ customers), delivery app (10+ partners). JWT and OTP, store-level RBAC. If stock, GST, and cash do not reconcile across those three, you do not have a grocery OS — you have three apps that argue.
Dual sales
In-store POS and mobile orders share stock, transfers, expiry, GST receipts, and cash reconciliation. That is the unglamorous core. Location-based ordering on Expo and delivery on Capacitor with photo + OTP proof only work if the ledger is one ledger.
The counter is a desktop
React + Electron POS: barcode checkout, thermal printing, S3 auto-updates. A PWA that “works on a phone” is not what a cashier will trust at 8pm. The UI has to survive gloves, glare, and a scanner that beeps twice.
Ops that a mart will actually run
WebP variants on S3, FCM / WhatsApp / SMS alerts, Telegram stock reports. None of that is a landing-page bullet. It is how a store finds out milk is gone without opening a laptop.
Why this is an India-shaped problem
GST, cash, multi-store RBAC, and delivery partners who are not a Silicon Valley fleet. I would rather write this than another “what is Node http vs https” note. If you are hiring for product that has to survive a real till, the case study is the resume. Related: search you can afford and how I work.
FAQ
- What is The Kirana Point?
A multi-store grocery platform I built end-to-end: POS for 30+ employees, a customer app, and a delivery app, with two marts live on the same API.
- Why Electron for POS?
Barcode checkout, thermal printing, and auto-updates on a real counter. The browser tab is not a cash drawer.