Sawasheri Brothers has sold groceries in Vadagaon, Belagavi since 1972. It started as a modest storefront, became a wholesale destination in 2018, added farm-fresh vegetables and dairy in 2023, and today supplies local families, retailers, and over 50 hotels and restaurants.
In 2026 they came to us to put that shop online. The result is Sawasheri Direct.
The Shop Is Not A Marketplace
The instinct with a grocery business is to reach for a standard e-commerce template. It is the wrong instinct, and it is worth being precise about why.
A marketplace assumes a stable catalogue, a fixed price list, and one kind of buyer. A kirana shop is none of those things:
- Prices move. Not quarterly — with the market. Onions are not priced the way a t-shirt is priced.
- Stock changes through the day. What sold out at 11am is back at 4pm.
- Buyers are not alike. The same shop serves a household buying a week of staples and a restaurant buying in bulk.
- Reordering dominates. A grocery customer does not browse. They buy roughly the same basket, repeatedly, and anything that adds friction to that loses to a phone call.
None of that is exotic. It is simply how the business already worked before software arrived, and the software had to fit around it rather than the reverse.
The Constraint That Shaped Everything
Here is the decision that mattered most, and it was not technical.
A shop of this size cannot fund a ground-up product build, and — more importantly — does not need one. The ordering flow a grocery business needs is well understood. Browse, search, cart, checkout, slot, track. Rebuilding that from first principles for every client would be expensive for them and repetitive for us.
So Sawasheri Direct is a branded deployment of our Grocery Platform, not a bespoke build. The platform ships a customer app, an admin dashboard, an admin app and a delivery app. Sawasheri Brothers took three of the four.
That is the model working as intended: take the pieces the business actually needs, skip the ones it does not.
What We Delivered
Customer ordering app
A native app for iOS and Android, live on both stores. Browse, search, cart and checkout, plus the things a grocery buyer specifically needs: quick reorder for repeat baskets, real-time order tracking, and delivery slot selection — express or scheduled.
The reorder path got disproportionate attention. If buying the same fifteen items again takes more than a few taps, the customer picks up the phone instead, and the app has failed at the one job it was built for.
Admin dashboard
This is the piece that decides whether a project like this survives contact with a real shop.
Staff manage the catalogue, categories, pricing and availability themselves. They review incoming orders and manage delivery. None of it requires touching code, and none of it requires waiting on us.
That last point is not a feature — it is the whole design goal. A grocery catalogue that only the developer can edit is not a working system. It is a bottleneck with a login page.
Landing page
A public page for the business: what they sell, where they deliver, opening hours, and the route into the app.
Technology
The customer app is React Native, so one codebase serves both stores. The dashboard and landing page are Next.js. The platform is configured and rebranded per vendor rather than forked, which means improvements flow to every deployment instead of stranding each client on their own snapshot.
Three Things That Were Harder Than Expected
Delivery slots are a scheduling problem, not a dropdown
The naive version is a list of time windows. The real version has to account for how many orders a slot can absorb, how far apart the delivery addresses are, and what happens when a slot fills while someone is mid-checkout.
Getting this wrong is not a UI bug — it is a promise to a customer that the shop then cannot keep. We would rather show fewer slots than show one that quietly over-commits the delivery team.
"Out of stock" needs a plan, not a flag
In a supermarket app, an unavailable item is simply hidden. In a kirana shop, the customer usually still wants something — a different brand, a different size, or a call asking what to do.
Marking an item unavailable is the easy part. Deciding what the customer sees next, and how the shop communicates a substitution, is the part that determines whether they order again.
Catalogue entry is the real onboarding cost
Nobody talks about this in a proposal, and it is often the largest single block of work when going live. Hundreds of products need names, categories, units, prices and images before the app is worth opening.
We built the dashboard around bulk entry and quick editing for exactly this reason. An admin panel optimised for changing one product at a time is pleasant to demo and painful to launch with.
Where It Stands
- Customer app — available on the App Store and Play Store
- Admin dashboard — live, in use by the business
- Landing page — final stages before launch
We are not publishing performance figures for this project. It is early in its rollout, and numbers quoted this soon would say more about our marketing than about the shop's business. When they mean something, we will publish them.
What We Would Tell The Next Vendor
If you run a single-vendor retail business and you are considering going online, the useful question is not "custom or template?". It is:
Which parts of this are genuinely specific to my business, and which parts am I about to pay someone to reinvent?
For Sawasheri Brothers, the specific parts were the catalogue, the delivery areas, the brand, and the relationship with regular customers. The ordering mechanics were not specific at all — and paying to rebuild them would have bought exactly nothing.
