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.