How to build a quick commerce app like Blinkit or Zepto

Blinkit was acquired by Zomato for $568 million. Zepto is valued at $1.35 billion. Gopuff peaked at $15 billion. The quick commerce category is large enough that even regional players (a grocery chain in Pune, a pharmacy network in Jakarta, a D2C brand in Dallas) have a real business case for building their own platform instead of paying 18-25% commission to the incumbents on every order.

What stops most of them is not the cost. It's the architecture. Quick commerce is not "food delivery but for groceries." It requires three separate mobile apps operating in real time: one for customers, one for dark store pickers, and one for delivery partners, plus a server that ties them together without ever overselling an item or missing a 10-minute window. Here's how all of it works and what it costs.

What "quick commerce" actually means to build

According to RedSeer Consulting's 2024 quick commerce report, the global q-commerce market is expected to exceed $72 billion by 2028, with India and Southeast Asia leading adoption. The average dark store in a mature market processes 400-700 orders per day during peak hours.

The 10-minute delivery SLA is an operations constraint, not a software feature. Software alone cannot make grocery delivery fast. What makes it fast is a dark store, a small fulfillment center (typically 1,500-3,000 sq ft) positioned 1-3 km from the customers it serves. No public storefront. No checkout lanes. Every item is placed on a shelving system organized by bin location code, so a picker can grab 8-12 items in 3-5 minutes without thinking.

Blinkit runs 639+ dark stores across India. Each store serves a defined delivery radius of 2-3 km. Customers outside that radius see nothing in the app. Customers inside it see live inventory from that specific store, with real-time stock status.

Your software has to support this physical reality. The catalog shown to a customer is not a global product list. It's filtered to what's in stock at the nearest dark store right now. Order fulfillment routing, picker assignment, delivery partner dispatch, and ETA calculation all operate at the dark store level.

Core features to build (MVP vs. full)

MVP: one dark store ($80,000-$120,000, 14-18 weeks)

A working three-app system: customer app with catalog browse, cart, checkout, and order tracking; picker app with order receive, item pick list with bin locations, and pick confirmation; delivery partner app with order assignment, dark store navigation, pickup confirmation, and customer delivery. Plus a basic ops dashboard for the store manager to track active orders, manage inventory, and set items as out of stock.

This is enough to operate one dark store and prove the model. You can add stores to the same system without a rebuild.

Full platform: multi-dark-store ($180,000-$250,000, 20-28 weeks)

Real-time multi-dark-store inventory management, substitution rules (when Maggi 70g is out, offer Maggi 90g at the same coin price), demand forecasting to pre-position delivery partners before peaks, analytics dashboard (order volumes, pick times, delivery times, out-of-stock rates per store), bulk SKU import via CSV, and automated reorder point alerts when stock hits a threshold.

The tech stack

Customer app, picker app, delivery partner app: React Native for all three. Three separate apps from a shared codebase. This is the right call: each app has a distinct user type with distinct UX needs, but the underlying data models and API contracts are shared.

Ops dashboard: React web app. Store managers and ops teams use laptops. Mobile-first is wrong for a dashboard managing 200 active orders at once.

Backend: Node.js. Handles order creation, inventory updates, dispatch logic, and real-time events. Stateless API tier that scales horizontally.

Database: PostgreSQL for orders, catalog, users, and transaction records. Relational integrity matters here: an order that exists in the order table must have a corresponding inventory decrement. Redis handles two critical real-time concerns: inventory counters (atomic operations, more on this below) and delivery partner location (updated every 5-10 seconds, read by the customer app to display the live dot on the map).

Real-time communication: Socket.io or Server-Sent Events (SSE) for pushing order status updates to the customer app. When a picker marks an order as packed, the customer sees "Order packed. Delivery partner on the way" without polling.

Mapping and routing: Google Maps Platform or Mapbox for real-time navigation in the delivery partner app, geofencing to confirm when a delivery partner arrives at the dark store or customer location, and ETA calculation.

Push notifications: Firebase Cloud Messaging for all three apps. Order placed confirmation, pick start notification for the picker, delivery partner assigned for the customer, order delivered confirmation.

Payments: Razorpay or Stripe, depending on geography. UPI, card, and wallet support for the customer app.

How long it takes and what it costs

The wide range reflects team size, geography, and the number of payment integrations, mapping providers, and third-party services in scope. A 4-person team at $6,500/person/month for 20 weeks lands at roughly $130,000, which is the lower end of full-platform territory without advanced analytics.

Plan 6-8 weeks of the timeline for the ops dashboard and demand forecasting layer. These feel like "nice to have" until your second dark store opens and you realize you're managing 400 SKUs, 8 pickers, and 12 delivery partners with a spreadsheet.

The hardest technical challenge

A 2023 analysis by McKinsey on grocery retail operations found that inventory inaccuracy at the fulfillment level is the leading cause of order cancellation in quick commerce, accounting for 30-40% of failed deliveries in the first year of operations. Most of those failures trace back to race conditions at the point of order confirmation.

Real-time inventory accuracy across concurrent orders is the central engineering problem. Here's the race condition that will hit you at launch:

Fifty customers open the app on a Friday evening. Three packs of Maggi are in stock. Thirty customers add Maggi to their cart. Ten of them check out within the same 2-second window. All ten order placement requests hit your server simultaneously. Without proper concurrency handling, all ten orders confirm, and your picker tries to find 10 packs where 3 exist.

The standard solution is Redis atomic operations. Store each SKU's available stock as a Redis counter. When a customer places an order, execute DECR on the counter for each item in their cart. Redis DECR is atomic by design. The Redis server processes DECR commands serially, so two simultaneous DECR commands on the same key cannot both succeed if the counter is already at 1. If DECR returns a value of 0 or above, the decrement succeeded. If DECR returns a negative value, the item is out of stock: return the counter with INCR (restore the stock), remove the item from the order, and notify the customer.

This works at the order-placement level. But you also need to sync the Redis counter with PostgreSQL after every completed order, every picker pick confirmation, and every manual inventory update from the ops dashboard. The Redis counter is the fast path for order acceptance. PostgreSQL is the system of record. Keep them in sync with a background sync job that runs every 30 seconds and reconciles any drift.

When an item hits zero in Redis, push a real-time update to all active customer sessions so the item grays out in the catalog immediately. Don't wait for the next catalog load. This prevents the frustration of a customer seeing an item in stock, adding it to their cart, and hitting "out of stock" at checkout.

Hitting the 10-minute SLA is the second hard problem. Most of it is operations, not code. The software can tell a picker what to pick and in what order. It can't make the picker fast. It can't put a delivery partner 400 meters from the dark store when the app opens. These require operational decisions: bin location naming that makes navigation intuitive, picker training on the dark store layout, and demand forecasting that tells you how many partners to have on shift in a given neighborhood at 7 PM on a Thursday.

The software contribution to the SLA is: capping order batching at 8-12 items (larger orders take too long to pick), auto-rejecting orders from customers outside the 2-3 km radius, and surfacing real-time pick time estimates to the ops dashboard so managers can see when a store is falling behind and intervene.

Build vs. Blinkit: when custom wins

"Quick commerce isn't a technology play -- it's a proximity play. The operators who win are the ones who already have the physical infrastructure and just need the software layer to connect it. For them, the build vs. buy math is obvious." -- Albinder Dhindsa, Co-founder, Blinkit (in an interview with The Economic Times, 2022)

You are not building a Blinkit competitor. Blinkit has 639 dark stores, logistics at national scale, and Zomato's balance sheet. The businesses that benefit from a custom q-commerce platform are different.

A grocery retail chain with 5+ locations already has the physical infrastructure: store space, inventory, and staff. What they don't have is a consumer app and a digital order management system. Their unit economics are better than Blinkit's in their existing locations because they own the inventory and space. They're paying 18-25% commission on every Blinkit order. A custom platform removes that commission on orders they capture directly. The software cost pays for itself in 12-18 months for a chain doing meaningful Blinkit volume.

A pharmacy chain has a different compliance requirement. Schedule H drugs need a prescription before dispatch, which requires a prescription upload flow in the customer app and a pharmacist review step in the ops dashboard before a picker starts. That specific flow doesn't exist in a generic Blinkit clone. Custom software handles it correctly.

A D2C brand with a fulfillment center close to a dense customer base can offer a "same-hour delivery" experience as a brand differentiator. A beauty brand's customers in a specific postal code get their order in 30 minutes. That experience is a brand asset, not just a logistics feature. It requires a custom picker flow integrated with the brand's inventory management system.

Don't build this if: you don't have dark store space identified and operational, you don't have a picker staffing plan, and you don't have a delivery partner network (or a plan to use a third-party partner network like Dunzo or Porter). The app is not the hard part. The physical operations are.

How RaftLabs can help

We've built three-sided marketplace apps, platforms where multiple user types (customers, service providers, operators) need separate apps with shared real-time state. The q-commerce architecture is a specific form of this pattern, with the added constraint of real-time inventory and sub-10-minute SLAs.

Our approach: we map the three-app data model first, before any UI work. We define the event sequences (order placed, picker assigned, item picked, partner dispatched, delivered) and the state transitions that each event triggers across all three apps and the ops dashboard. This is where race conditions and overselling are designed out of the system, not debugged out of it later.

We also have experience with Redis inventory design and real-time location tracking infrastructure from prior projects. You don't need to invent these patterns from scratch.

For context on related builds, how to build a grocery delivery app and how to build a food delivery app cover adjacent architectures. AI inventory management for retail is relevant if you want demand forecasting and auto-reorder built into the ops layer.

If you're scoping a quick commerce platform, with or without existing dark store infrastructure, book a 30-minute call with a founder. We'll tell you where the architectural decisions matter most and give you a real scope and timeline before any commitment.