How I redesigned a hackathon billing app for the person actually standing behind the counter.

Kirana stores are India's neighbourhood grocery shops. Industry estimates put them at 12 million or more, and many still track bills and customer credit by hand.

At a busy counter, hands are full and time is short, so an app that needs a lot of typing, searching or menu-hopping is hard to use during a sale.

ShopEZ starts with the camera: place the items in view, the app recognises them, and the bill builds itself. Recognition runs on YOLOv8 through OpenCV, with a Flutter app, a Flask backend and Supabase behind it. It was built as a hackathon prototype.

Here is what the problem rests on, and what it does not. I did not interview shopkeepers or run usability research. My understanding comes from watching a relative who runs a kirana store track transactions by hand, from web research, and from the team's own reasoning. Read it as one shop's view plus desk research, not as a study.

The original app, built by the team over the hackathon, could scan items and generate a bill. That was roughly it. My part was the UX flow and a basic UI, drawn up quickly because the clock was running.

The home screen opened to a customer list with no business summary. Credit tracking was buried. The first screen asked users to choose between “Retailer” and “Customer,” a choice a shopkeeper-only tool never needed.

A year later I came back to it on my own: a full UI redesign, a second pass on the UX, and some Flutter front-end work to carry parts of it into code. The question I started from was simple:

The redesign is mainly a UI and UX redesign. I carried some of it into Flutter, and the rest lives in the designs. I have not marked each feature as built or not, so treat it as a design-stage concept with partial implementation.

Leading with the camera

The camera-first idea, sketched: items on the counter, scan, bill.

At the counter the items are already in front of the shopkeeper. Searching a catalogue means typing and scrolling for every item, so the app starts from what is physically there: place the items in view, scan, and get a bill. In our tests we put several grocery items together and scanned them in one go.

The cost is that the whole flow depends on recognition. It worked best on packaged items and struggled with loose or unpackaged ones. That limit is why the next decision matters.

Making the AI visible, not invisible

YOLOv8 returns a confidence score for every item it detects. Rather than hide it, the concept shows it per item: a 95% detection reads green and an 88% one reads amber, so the shopkeeper can tell which to glance at twice.

We tried a range of grocery items. Packaged goods were recognised more easily. Loose items were harder, and changed packaging could throw the model off. So every bill goes through a review step, and any item can be added manually, which also covers anything the model does not recognise.

The Walk-in Customer button

The first version asked for a customer on every bill, as if each sale belonged to a registered customer.

My assumption, from watching one store and not from data, was that plenty of sales are quick cash sales that do not need a customer record, and a lookup on every one is friction. So “Walk-in Customer” skips selection and goes straight to payment. Customers on credit still get the full flow, with recent customers at the top.

Payment offers cash, UPI and credit. Those three came from our own product reasoning, not from a payment-methods study.

Words on a button

The bill summary screen originally ended with “Confirm Transaction,” which sounds formal and final, like a bank.

By that point the sale is already under way: it started a few screens earlier, when the camera scanned the first item. A confirmation step makes it feel like starting again. “Continue to Bill” says the work is nearly done. This was a judgement about wording, and I have not tested it with shopkeepers.

Digitising udhaar without making it awkward

The udhaar cycle, sketched: credit given, noted in the khata, payment received.

Udhaar is credit given on trust, usually written in a paper ledger called a khata. The shopkeeper often knows the customer personally, which makes asking for payment uncomfortable. The goal was to digitise those records and take some of that awkwardness out.

The billing flow in one strip: scan, review, select a customer, and settle the payment.