The problem nobody built for
Walk into any Indian neighborhood and you'll find one within 200 meters: a kirana store. A shopkeeper who knows your family's grocery list better than you do, sells rice by the fistful, and has been running the same ledger-and-memory system for twenty years.
Now walk through the Open Network for Digital Commerce (ONDC) — India's answer to letting any seller, not just Amazon or Blinkit, plug into digital commerce. In theory, this is exactly the lifeline kirana stores need to compete with 10-minute delivery apps. In practice, almost none of them are on it.
Why? Because getting listed means digitizing a catalog — hundreds of SKUs, prices, categories, descriptions — and typing all of that into a form is a full-time job the shopkeeper doesn't have time for. Half their inventory doesn't even have a barcode: loose grains, regional snacks, hand-weighed spices. There's no "Add to Catalog" button for a kilo of unbranded toor dal.
That gap — between wanting to go digital and having the hours to do it — is the actual bottleneck. Not technology access. Not willingness. Time.
The idea: let the camera do the typing
The insight behind Dukaan Digital is simple: a kirana shopkeeper already produces two documents every single day without thinking about it — a wholesale distributor's invoice, and a shelf full of visible stock. Both are already a complete inventory list. They just live in the wrong format.
So instead of asking anyone to type anything, the app asks for a photo.
Snap — a photo of a messy, possibly handwritten distributor invoice, or a photo of a crowded shelf.
Extract — Gemini 1.5 Flash reads the image and returns a structured list: product name, category, brand, quantity, unit, price, and whether it's a loose/unbranded item.
Describe — for the items that don't have a listing anywhere on the internet (loose grains, local snacks, regional produce), the model generates a short, catchy description on the spot, because nobody else is going to write one.
Review — extracted items show up as editable tags the shopkeeper can fix in ten seconds.
Export — one tap produces an ONDC-shaped catalog JSON, ready to feed into a seller-app integration.
What used to be an afternoon of data entry becomes a five-minute phone break between customers.
Under the hood
The stack is deliberately unglamorous, because the hard part of this problem isn't the architecture — it's the extraction accuracy on genuinely messy, real-world input.
Vision & extraction: Gemini 1.5 Flash, prompted to return strict JSON (name, category, brand, quantity, unit, price,is_loose_item, description, confidence) — no prose, no markdown fences to strip.
Validation: every model response gets checked against a Pydantic schema before it's allowed near a database. Malformed individual items get silently dropped instead of failing the whole scan — a photo with 40 products shouldn't fail because one line was unreadable.
Backend: FastAPI, five routes — scan, save, list, delete, export.
Storage: SQLite. A single-store prototype doesn't need more than that yet.
ONDC mapping: the saved catalog gets shaped into something that mirrors an ONDCon_searchpayload —bpp/providers→items[], each with a descriptor, price, and quantity block.
The part I spent the most time on
Not the API calls — the prompt. Getting a vision model to reliably parse a handwritten invoice, in someone else's handwriting, with abbreviations and crossed-out quantities, is a genuinely different problem from reading a printed receipt. The prompt has to explicitly tell the model to fix spelling, expand abbreviations, and flag its own confidence — because a shopkeeper reviewing extracted data needs to know at a glance which line to double-check, not just trust everything blindly.
The other deliberate choice was making loose/unbranded items a first-class concept instead of an edge case. A bag of Lay's has a barcode, a price, and a Wikipedia-adjacent amount of existing metadata. A kilo of local makhana from the shop two streets over has none of that — and that's exactly the inventory ONDC listings tend to ignore, because it's the hardest to catalog by hand. If this tool only worked for branded FMCG goods, it would be solving the easy 60% of the problem.
What it looks like in practice
The interface leans into what a kirana shop actually looks like rather than defaulting to a generic dashboard: a shop-signboard header, a ledger-paper background, and — the part that gets the best reaction in demos — every scanned item shows up as a hand-tag clipped to a string, slightly rotated, punch-hole and all, exactly like the price tags already hanging in these stores. The shopkeeper isn't learning a new mental model. They're looking at a digital version of something they already touch every day.
What's still rough
This is a working prototype, not a finished product, and it's worth being honest about the gaps:
- The ONDC export mirrors the shape of a real catalog payload but hasn't been validated against the official protocol headers and versioning — that's the natural next step once there's an actual seller-app sandbox to test against.
- Extraction accuracy is only as good as the photo. Low light or extreme clutter still needs a retake.
- No multi-store or auth support yet — this is built for one shopkeeper at a time.
Why this matters beyond one shop
ONDC's entire premise is that small sellers shouldn't need a tech team to compete with platforms that have one. If digitization keeps requiring manual data entry, the network ends up onboarding the shops that were already digital-first — which defeats the point. A camera-first cataloguing flow isn't a nice-to-have feature; it's the difference between ONDC reaching the kirana stores it was actually built for, or reaching only the ones that didn't need the help in the first place.
Built as a submission for Gen AI Academy APAC — vision-based product cataloguing for ONDC, using Gemini 1.5 Flash for extraction and FastAPI for the backend. Code and setup instructions available on request.