Case study · Retailer + customer shop SaaS
OrderEasy
A billing counter for a neighbourhood shop, and an ordering app for the customers who already know it.
The problem
A kirana or general store in India bills at the counter, keeps a credit book for its distributors, and takes phone and WhatsApp orders from regulars. Those three jobs usually live in three places: a billing app, a notebook and a phone.
Marketplaces solve a different problem. They put the shop next to its competitors and take a cut. The shop wanted its own regulars to order from it, with stock and bills that agree.
My part
Sole builder: the Django platform, the retailer web app and POS, the customer web and Android app, the end-to-end test suite, deploys, the demo captures and the support inbox.
Built with
- Python, Django, REST APIs
- React + TypeScript (retailer and customer)
- Capacitor for Android
- Playwright end-to-end suite
- Cloudflare
What I built
- A phone-first POS: single-column bill, camera barcode scanning that stays open between scans, server-side catalogue search.retailer_ordereasy_njs #145 ↗
- Inclusive GST with HSN codes across POS bills, online orders, purchase invoices and returns, with sale-time rates snapshotted so an old bill never changes.RetailerCustomerPlatform #103 ↗
- Exact-amount UPI QR per order and per POS bill, split bills included, printed on thermal receipts.retailer_web_build @ 588bfd2 ↗
- Distance-based delivery fees: flat or tiered by km, shown to customers by their GPS pin, enforced at checkout.RetailerCustomerPlatform #200 ↗
- Open shop sign-up with a five-step verification and one admin approval before customers can see the shop.retailer_ordereasy_njs #158 ↗
- Customer reports for products and shops that go to a review queue, never an automatic takedown.customer_ordereasy_njs #103 ↗
- The customer app wrapped for Android with native Google sign-in and UPI apps opened directly.customer_ordereasy_njs @ e3d0112 ↗
Calls I made
Not a marketplace
Customers open the shop they already know. There is a city list, but no ranking, ads or commission. That keeps the product on the shop’s side and keeps the scope small enough for one person to support.
Snapshot tax at the moment of sale
GST rates and HSN codes are copied onto each line when it is sold. Changing a product’s rate later can’t rewrite last month’s bills, which is what an accountant checks first.
RetailerCustomerPlatform #103 ↗Search on the server, not in the browser
The POS first loaded the whole catalogue, and after one deploy the product list timed out in production. The fix moved search to the server with a per-shop cache that clears on every stock or price change, and exact lookups for scanned barcodes.
retailer_ordereasy_njs #157 ↗Reports flag, people decide
A customer report or a strike never hides a product or suspends a shop by itself. It goes to a review queue, and the retailer is told what is held and how to fix it. One angry customer can’t take a shop offline.
customer_ordereasy_njs #103 ↗A test gate that uses the real storefront
Playwright journeys cover POS bills, the order lifecycle, khata, reports, offers, inventory and delivery fees against a local stack that blocks every live host. The first run found bugs that unit tests had missed.
RetailerCustomerPlatform #217 ↗Every line above links to the merged pull request or commit it describes. Screens are real captures on seed data. Vineet Sharma.
Next case studyCiteBench →