Building an Online Grocery System in India: How We Shipped Web + Customer App + Driver App for Jai Shri Balaji Store

In Q1 2026 we shipped Jai Shri Balaji Store — a full online grocery system for a Delhi-NCR retailer. Not just a website. The complete operational stack: a customer-facing storefront for browsing and ordering, a customer mobile app for on-the-go shopping with order tracking, and a delivery driver app with route optimization and proof-of-delivery. Three apps. One backend. Twelve weeks from kickoff to launch. This case study covers the architecture, the decisions, the costs, and what we'd do differently if we built it again today.

“Most Indian grocery clients ask us 'just build me a website like Blinkit.' What they actually need is what Blinkit needs — a 3-app system, not just a storefront. The storefront brings the customer in. The customer mobile app keeps them. The driver app is what keeps the business running. Skip any of the three and the unit economics fall apart by month 4.”

The client and the problem

Jai Shri Balaji Store, founded and run by Ashok Dhull, had been operating as a traditional kirana + light wholesale operation in Delhi-NCR for over a decade. WhatsApp orders, walk-ins, occasional Zomato/Swiggy via a partnered cloud kitchen. Ashok wanted to capture the modern home-delivery grocery market without the heavy infrastructure cost of a Blinkit or Zepto-style dark-store model.

Their constraints were specific and Indian:

• INR-flat budget around ₹8–12 lakh for the entire stack — not the ₹50L+ that funded grocery startups spend
• Existing customer base on WhatsApp (~600 regular households) that needed a smooth migration path
• No internal tech team — the system needed to be operable by a non-technical store manager
• Two warehouses (one main, one satellite) with different SKU subsets and pricing
• Razorpay-first payments (they already had a Razorpay account, hated the idea of forex)
• Hindi-friendly UI alongside English (most customers shift between both)

Why 3 apps instead of 'just a website'

Every grocery client we've worked with starts the conversation asking for 'a website like Big Basket.' What they don't realize is that the website is the smallest part of the system. Here's why we always push for a 3-app architecture for serious grocery operations:

Website (responsive, fast)

Captures Google traffic and search intent. New customers find you here. SEO matters. Performance matters. Works for browsing on a desktop or quick orders on mobile browsers. The website does about 30-40% of revenue volume in a typical Indian grocery business.

Customer mobile app

Locks in repeat customers. Push notifications drive re-orders. Faster checkout via saved details + cart memory. Offline browsing works (we cache the catalog). The customer app does 50-60% of revenue once a business hits 6+ months of operation — repeat business is where margins live.

Delivery driver app

This is the part everyone underestimates. The driver app is what keeps your unit economics positive. Real-time order assignment, route optimization, proof-of-delivery (signature + photo + OTP), driver attendance, payout tracking. Without this, your store manager is sending WhatsApp screenshots to drivers and calling them every 20 minutes. That model breaks at 50 daily orders.

The architecture (high level)

Three apps. One backend. One database. One admin panel for the store manager. Here's how the pieces connect:

• Storefront (Next.js + Vercel) → reads catalog from API, places orders via API
• Customer mobile app (Flutter, iOS + Android) → same API, push notifications via FCM
• Driver app (Flutter, Android only) → same API, real-time order assignment via WebSocket, GPS tracking
• Backend API (Node.js + Express, hosted on CloudNX Mumbai region) → handles auth, orders, payments, inventory, driver dispatch
• Database (Postgres + Redis) → Postgres for transactional data, Redis for cart sessions + real-time driver state
• Admin panel (Next.js on same Vercel project) → operated by store manager, manages catalog, orders, drivers, payouts

Single source of truth: the backend. The three apps are essentially three different UIs over the same data. This is the most important architectural decision in any multi-app system — and the one most cheap builds get wrong, ending up with three apps that have their own little databases that get out of sync.

Why Next.js for the storefront (not Shopify, not WooCommerce)

Most Indian grocery clients ask us 'should we just use Shopify?' For Jai Shri Balaji Store, the answer was no, and here's why:

• Shopify's per-transaction fees compound quickly on a high-volume, low-margin grocery business
• Shopify can't natively integrate with a custom driver app and warehouse inventory the way we needed
• Customer mobile app and driver app need the same backend the website uses — Shopify's API model is read-heavy, not designed for a unified backend
• ₹1,994/month Shopify Basic + transaction fees + apps = ₹15,000-₹40,000/month at scale. The custom Next.js storefront has zero per-transaction fees and runs on Vercel free tier until 100K+ visits.

Where we DO recommend Shopify: small grocery brands that don't need a driver app, are dropshipping or single-warehouse, and don't have 100+ SKUs per category. For most operational grocery businesses with their own delivery fleet, custom Next.js wins on cost-per-order.

Why Flutter for both mobile apps (not React Native, not native)

We use both Flutter and React Native in production. For this project we picked Flutter for three specific reasons:

• Performance on low-end Android phones — most Indian delivery drivers have ₹8K-15K phones. Flutter's AOT-compiled Dart runs noticeably smoother than React Native on these devices.
• Single codebase, two apps — we built the customer app and driver app from the same Flutter codebase with shared core packages. ~40% code reuse.
• Mature offline support — Flutter + Hive (local DB) made the offline catalog and offline cart functionality trivial. The customer keeps browsing during a metro tunnel ride.

If your client team has more React experience and wants to hire React Native devs in-house later, RN remains a fine choice. For this project, Flutter was the right call.

The Razorpay vs Stripe decision

Razorpay won this one easily. Reasons specific to Indian grocery:

• UPI integration is native, fast, and the way 80%+ of Indian grocery customers pay in 2026
• INR settlement to an Indian bank account, no forex variance
• GST-compliant invoices auto-generated for B2B grocery clients (kirana shops reselling)
• QR code payments for cash-on-delivery upgrade to digital (we built this — driver shows QR, customer pays, no cash handling)
• Subscription billing for households who pay a monthly grocery deposit

Stripe is excellent — but it's not how Indian grocery customers want to pay. We use Stripe for international SaaS clients, never for India-only grocery.

Multi-warehouse inventory architecture

The two warehouses (main + satellite) was the trickiest part of the build. The system needed to:

• Show different SKUs at different warehouses (some products only in main warehouse)
• Show different prices at different warehouses (satellite has higher prices due to operational cost)
• Auto-route orders to the nearest warehouse with stock
• Allow store manager to manually override the warehouse if needed
• Show inventory in real-time so customers don't order what's already sold out

We modeled this as a 'warehouse-product' join table with location, stock, and pricing per warehouse. When a customer searches, we compute their nearest warehouse from their PIN code (we maintain a pin-to-warehouse mapping table for the service zones), then filter the catalog by that warehouse's stock + pricing. The system gracefully handles warehouse outages — if the nearest warehouse is offline, it shows the next-nearest warehouse's catalog without the customer noticing.

Route optimization for the driver app

This is where the driver app earns its keep. When a driver picks up multiple orders for delivery (typical: 4-8 orders per route), the app computes the optimal sequence using:

• Google Maps Distance Matrix API for current traffic-aware distances between all pickup → delivery points
• A simple greedy nearest-neighbor algorithm with proximity bucketing (perfect optimization is NP-hard; we use the 'good enough' variant)
• Time windows where customers said they want delivery (e.g., 6-8 PM slot)
• Driver-specific constraints (some drivers handle 2-wheelers only, can't do bulk orders)

The result is a delivery route that's roughly 20-30% shorter than 'in the order they were placed.' Multiply by 60+ deliveries per driver per day, and the time savings are real — each driver does ~15% more deliveries per shift than they would without route optimization. That's a 15% productivity bump on the most expensive operational cost (driver wages).

The build timeline (12 weeks)

We worked in 4 sprints of 3 weeks each, with the client approving each milestone before the next started:

1. Sprint 1 (Weeks 1-3): Backend API + database schema + admin panel + storefront (catalog browsing only, no payments)
2. Sprint 2 (Weeks 4-6): Storefront payment flow + customer mobile app (with order placement) + Razorpay integration
3. Sprint 3 (Weeks 7-9): Driver app + route optimization + warehouse inventory management + push notifications
4. Sprint 4 (Weeks 10-12): Multi-warehouse logic + production hardening + launch + 2 weeks of post-launch bug fixes

The client was actively involved — store manager joined every Friday demo call, gave feedback within 48 hours, and tested every feature before we moved on. This is the #1 reason the project shipped on time. Clients who 'check it when it's done' are the reason most agency projects run 50-100% over schedule.

The actual costs (transparent INR)

One-time build cost

• Customer storefront (Next.js, 5 pages, catalog, cart, checkout): ₹1,80,000
• Customer mobile app (Flutter, iOS + Android, full order flow): ₹2,40,000
• Driver app (Flutter, Android, route optimization, GPS, proof-of-delivery): ₹2,10,000
• Backend API + database + admin panel: ₹2,40,000
• Razorpay integration + GST invoicing + subscription billing: ₹60,000
• Multi-warehouse logic + pin code mapping: ₹50,000
• Push notifications + WhatsApp order updates: ₹30,000
• Total build: ₹10,10,000 (well within client's ₹8-12L budget)

Ongoing monthly costs (the client's actual budget)

• Vercel Pro (storefront + admin) — ₹1,500/month
• CloudNX Mumbai region (backend + database) — ₹3,500/month
• Google Maps API (route optimization) — ₹2,000-₹6,000/month depending on volume
• FCM push notifications — free up to high volume
• Razorpay transaction fees — 1.9% per transaction (~₹15-30/order at average ticket size)
• Apple Developer Program — ₹8,000/year
• Google Play Console — ₹2,000/year one-time
• Total monthly running cost: ₹7,000-₹12,000/month + Razorpay transaction fees

What we would do differently if we built it again today

1. Skip the customer iOS app at launch

About 92% of the client's customer base is on Android. We built iOS anyway because 'launch parity feels right.' In hindsight, we should have shipped Android-only for the customer app in v1 and added iOS in month 4 once revenue justified it. Would have saved ~₹50,000 in build cost and 2 weeks of iOS-specific App Store review delays.

2. Use Supabase for auth + realtime instead of custom Node.js

We built custom JWT auth + WebSocket dispatch in Node.js. Worked great. But Supabase's combination of Postgres + auth + realtime subscriptions would have saved us about 3 weeks of work for the same outcome. Their pricing fits this scale (~₹2,000/month) and offloads the auth/realtime maintenance.

3. Cache the catalog more aggressively in the customer app

The customer app fetches the catalog fresh on every cold start. We later added 5-minute caching. We should have done 24-hour caching with a background refresh from launch. Customers don't need real-time catalog updates — they need fast app open times.

If you're building something similar — costs to expect

For an Indian grocery business building a 3-app system in 2026, realistic budget ranges (full custom, no SaaS lock-in):

• Solo storefront only (Shopify or simple Next.js, no driver app): ₹85K-₹2.4L
• Storefront + customer mobile app (no driver app — you use WhatsApp/manual dispatch): ₹3.5L-₹6L
• Full 3-app system (web + customer app + driver app) like Jai Shri Balaji: ₹8L-₹15L depending on complexity
• Blinkit/Zepto-scale dark-store stack (50+ warehouses, real-time inventory, marketplace dispatch, complex pricing): ₹40L-₹1.5cr

If a 'grocery app developer' is quoting you ₹3 lakh for a 'complete Blinkit clone with all features' — they're either using a white-label SaaS template (you'll outgrow it in 6 months) or they're going to disappear before completion. Real builds in this category cost what they cost.

The operational outcome (3 months in)

Three months after launch, here's where Ashok's team at Jai Shri Balaji Store is:

• 120-180 daily orders, up from ~30 on WhatsApp pre-launch
• 60% of new orders coming through the customer mobile app
• Average ticket size ₹420, average margin per order ~28% (typical Indian grocery)
• 4 delivery drivers active, doing 30-40 deliveries each per shift
• Customer retention at week 4: 64% (industry average is around 50%)
• Store manager spends ~2 hours/day on admin panel, vs 6+ hours of WhatsApp chaos pre-launch

The unit economics are positive. The system pays for itself (build cost amortized over 18 months) by month 14 at current growth rate.

“buildbyRaviRai built our entire system in 3 months — website, customer app, and driver app — all working together. Before this, we were managing 30 daily WhatsApp orders chaotically. Today we do 150+ a day with less stress than we had at 30. The driver app alone changed how our team operates. Ravi and the team understood our business, not just our tech requirements.”

Want to talk to us about something similar?

If you're scoping a grocery business, dark-store, marketplace, or any operational e-commerce business with delivery — we'd genuinely like to talk. We've built 4 different operational e-commerce systems in 18 months (grocery, pharmacy, restaurant chain, B2B wholesale). The architecture decisions are similar; the business models and unit economics are very different.

First conversation: 20-min call, free, project fit only — not a sales pitch. We'll ask about your existing operations, your delivery model, your warehouse setup, and your real budget. By the end of the call we'll tell you honestly whether we're the right partner or whether you should look elsewhere.

Click through the live system

If you want to see the storefront live: https://jaishribalajistore.com — it's a working production grocery store, not a demo. Place a small order, see the flow, watch the order status update in real-time. The customer mobile app is on Play Store and the driver app is internal-only (Play Store private channel) but we can demo it on a screen-share if you want to see the route optimization.