How to Start a 10-Minute Grocery Delivery Business

India’s 10-minute grocery delivery market has already proven itself. Blinkit, Zepto and Swiggy Instamart have trained tens of millions of urban shoppers to expect milk, medicine and last-minute party supplies at their door in minutes, and they have built billion-dollar valuations doing exactly that.

You don’t need Blinkit’s balance sheet to enter this category. The model is fundamentally local: a single dark store runs on its own economics, serving a two- to three-kilometre radius, independent of what a competitor is doing three localities away. That makes quick commerce one of the few high-growth e-commerce categories where a well-run, single-city operator can compete on service quality and local relationships rather than on funding.

This guide walks through what it actually takes to launch: the operational groundwork, the compliance you can’t skip, realistic costs, and the technology. For the technology half we show QuickKart, our ready-made quick commerce platform, screen by screen: the customer app, the rider app, the dark-store dashboard and the admin panel, all with real screenshots from the live demo instance rather than mock-ups.

How the 10-minute grocery model works

Quick commerce is not a smaller version of a supermarket, and it isn’t e-commerce with a faster courier bolted on. It runs on a different unit-economics model, built around three things: micro-warehouses, tight delivery radii and order frequency.

A dark store is a small, closed-to-walk-in warehouse, typically 1,000 to 3,000 square feet, stocked with the 1,500 to 3,000 fastest-moving SKUs across groceries, packaged food, personal care and household essentials. It sits inside the neighbourhood it serves, not on a highway or in an industrial zone, because the whole model depends on a rider reaching any customer in that zone within minutes. The location is chosen for delivery reach, not for cheap rent.

Margins per order are thin, often thinner than a kirana store once you account for delivery cost, packaging and the fee waivers used to win first-time customers. What makes the model work is repeat frequency, because the friction of ordering is close to zero. A supermarket shopper buys one large basket roughly once a month; a quick commerce customer buys many small baskets, several times a week, to the same households. That volume, not the margin on any single order, is what makes a dark store profitable, and it is why the location and delivery-radius decisions matter more here than in almost any other retail format.

For the feature-by-feature build view of the same problem, see how to set up a quick commerce app like Blinkit, Zepto and Instamart.

What you need before the first order: operations

Before any app enters the picture, quick commerce is an operations business. Get these right and the technology has something solid to run on:

• A dark-store location per zone. A compact, well-connected space (ideally under 3,000 sq ft) inside the 2-3 km radius you intend to serve, with easy two-wheeler access and room for basic cold storage.
• Initial inventory sourcing. Direct tie-ups with local distributors, FMCG stockists and wholesale markets for your first 1,500-2,000 SKUs, weighted toward high-frequency categories: dairy, produce, snacks and household essentials.
• Delivery riders. A trained rider base per store, sized to your expected peak-hour order volume, with clear SOPs for picking, packing and handover time targets.
• Local marketing and customer acquisition. Hyperlocal campaigns (society WhatsApp groups, local influencers, launch discounts) that build a repeat-ordering habit in your first few pincodes before you expand.
• Compliance. An FSSAI licence before you sell a single packaged or fresh food item, and Legal Metrology-compliant labelling (MRP, net quantity, manufacturer details) on every SKU you stock.

The technology: three apps and an admin panel, ready to brand

The technology layer is where most first-time founders either burn months of runway building the wrong thing, or launch with a generic delivery app that cannot do what minute-level delivery requires: serviceability by pincode, a live delivery promise, rider assignment, and a bill that discloses every charge before the shopper pays.

QuickKart ships all of it as one platform, sold as white-label source code rather than a SaaS subscription. Here is what is in the box:

The customer app: from pincode to doorstep

The customer app opens on a location gate. It resolves the shopper’s GPS position or a typed pincode against every live dark store’s geofence and pincode list, and answers with the store that will serve them and the delivery promise for that store right now. The “8 min” in the header of the home screen is that answer; the app never invents an ETA, and a closed or paused store says so instead of quoting one.

What the shopper can do, screen by screen:

• Browse before signing in. The catalogue, search and cart work as a guest; the guest cart merges into the account on sign-in.
• Find products fast. Live search suggestions, recent searches, category pages with facet filters, and sorting by relevance, price, newest or rating.
• See the whole product. Image gallery, variants, price against MRP with the discount badge, a declarations panel for pack size and legal details, customer reviews and a questions-and-answers thread. Out-of-stock variants are disabled rather than hidden.
• Build the basket. Quantity steppers, saved items, coupon entry with a list of the coupons available to that cart, a tip for the rider and an optional donation line, and a progress bar toward free delivery.
• Choose when. Express delivery is the default. Where the operator has switched on delivery windows, the shopper can ask for a later window instead, and the request travels to the store with the order.
• Pay with a bill they can read. Item total, savings on MRP, delivery fee, handling charge, cash-on-delivery charge and GST are separate labelled lines. The apps ship with cash on delivery and bank transfer as the payment methods; the online-gateway integration is covered below.
• Keep addresses. An address book with Home and Work labels, a default address, and a six-digit pincode check that refuses an unserviceable address before it is saved.
• Follow the order. Order history, one-tap reorder, cancellation while the store still allows it, and a live tracker with the ETA, an eight-stage timeline, a status message from the store, the handover code to read out at the door, and a map of the rider’s position once a rider is on the way.
• Manage the account. Edit profile, push notifications for order status changes, a help form that lands in the admin panel’s contact queue, store-credit and reward-point balances where the operator uses them, the privacy and terms pages, and in-app account deletion, which the app stores now require.

The rider app: assigned, picked up, arriving, delivered

Riders do not sign themselves up. The admin creates each rider account, sets the password and puts the rider on one or more dark-store rosters, so only people you have onboarded ever see an order. The app is deliberately small: a duty switch, today’s deliveries, one delivery at a time, and earnings.

• Go on and off duty. The Online switch tells the store which riders can take work. Going offline stops new assignments without dropping the deliveries already in hand.
• See the work as it is assigned. The store assigns a packed order to a rider from its board; the rider’s list refreshes itself while the app is open and online, with a countdown to each order’s promised time that turns to “running late” once it passes.
• Get there. “Navigate to store” and “Navigate to customer” open Google Maps with the destination filled in, and the call button dials the customer.
• Move the order along. Picked up, Arriving and Delivered are three taps, in that order, and the server refuses any step out of sequence.
• Hand over safely. When the operator has the handover code switched on, Delivered needs the four-digit code the customer sees in their tracker; five wrong attempts lock the order. For cash orders the rider also confirms the amount was collected.
• Share position. While a delivery is in progress the app sends the rider’s location to the server, which is what the customer’s tracking map shows.
• See the money. Today’s delivery fees and customer tips, trips and hours online, and a seven-day chart.

The dark-store dashboard and Store app: running the floor

Every dark store gets its own operator login, scoped to that one store. The same tools come as a web dashboard for the desk and as an Android app for the floor: a live order board, rider assignment, the assortment with prices and stock, delivery windows, and a pause switch for the moments when the store simply cannot take more.

• Live order board. Placed, Accepted, Picking, Packed, Assigned, Picked up and Arriving as columns, sorted by promise time. Each card shows its age and minutes to promise; it turns amber with two minutes left and red once the promise has passed. The board refreshes itself every fifteen seconds.
• Rider assignment. On a Packed order, pick from the riders who are on shift and active, ordered by who is carrying least. Reassign or unassign if plans change. The server refuses a rider who is offline or deactivated.
• Assortment and prices. Every SKU the store carries with price, MRP, what the shopper pays, on-hand and available stock, a listed switch, rack location and a per-order cap. Edits are staged and saved in one transaction; a price above MRP is refused.
• Pause with a reason. Weather, overloaded, stock-out, no riders, maintenance or other, with an optional note and an automatic resume time. A paused store stops quoting to new shoppers immediately; orders already placed are unaffected.
• Delivery windows. The Android app shows the day’s scheduled windows with bookings against capacity.

The admin panel: every dark store from one screen

The admin panel is where the operator builds the network: dark stores and their geofences, the promise engine, fee rules, riders, the catalogue and everything a marketplace back office needs around it. The screenshots below are from the demo instance.

Beyond the quick-commerce screens, the panel carries a full marketplace back office: categories as a drag-to-reorder tree, customers with groups, suspension, wallet adjustments and login history, cart and catalogue price rules with coupon generation, banners, sliders and CMS pages, newsletter campaigns and email templates, search synonyms and redirects, sitemap and SEO audit, inventory sources with adjustments, transfers and a movement log, tax classes, rates and rules with the India GST extension, sales, orders, customers, products, inventory, tax and coupon reports with CSV export, payment methods, staff users, locales, currencies and system settings.

Serviceability, the promise engine and disclosed fees

Three pieces of the backend do most of the work that makes a quick commerce app feel like one.

Serviceability. Each dark store owns a polygon geofence drawn on the map in the admin panel, a list of pincodes, opening hours, a prep time, a capacity per slot and a maximum delivery radius. A shopper’s coordinates or pincode are resolved against all of that, and against whether the store is open or paused right now, before the app shows a single price. Every lookup is logged, so the serviceability tester can show you which pincodes asked and were refused in the last thirty days: your expansion map, drawn by demand.

The promise engine. The ETA a shopper sees is built term by term from that store’s prep time, its current queue of open orders, travel distance at a configured average rider speed, a rider-wait term that only applies when every rider is busy, and a small buffer so the promise is beatable. The store detail page shows the breakdown live, so when a quote drifts to sixteen minutes you can see exactly which term moved. Nothing in the product hardcodes “10 minutes”.

The fee engine. Delivery, handling, surge, small-cart and cash-on-delivery charges are rules, not code: flat, percentage, distance-tiered or subtotal-tiered, platform-wide or per store, with a time window for surge. Each active rule becomes one labelled line on the bill, and the label the operator types is the exact wording the shopper reads before paying. That structure is what keeps a bill aligned with India’s Consumer Protection (E-Commerce) Rules on fee disclosure, and it is why there is no “other charges” line anywhere in the app.

Two more guards sit around the order itself: a handover code, minted per order and shown in the customer’s tracker, that the rider must enter before an order can be marked delivered (switchable in settings), and breach flags that mark any open order past its promised time in red on every board.

Built on a modern stack: what ships wired, and what you connect

The three mobile apps are Flutter. The storefront and admin panel are Next.js. The API is NestJS on Prisma and PostgreSQL, with Redis for caching and queues. Quick commerce itself is a platform module on top of a general marketplace core, so serviceability, the fee engine, delivery windows and OTP sign-in each switch on and off from the admin panel without a redeploy. You receive the full source code for every part under a one-time licence and host it yourself.

Because it is your deployment, a few integrations are yours to connect, and it is worth being clear about which:

• Payments. Cash on delivery works out of the box, including the COD surcharge rule. Bank transfer is built in with a receipt-approval queue for the admin. Razorpay is integrated in the backend and the web storefront and switches on with your keys; the mobile apps’ checkout ships with cash on delivery and bank transfer.
• Maps. The geofence editor in the admin panel and the rider map in the customer tracker use Ola Maps and need your Ola Maps key. Rider navigation opens Google Maps on the phone and needs nothing.
• Sign-in. Email and password work immediately. Phone OTP sign-in is built into the customer app and the API with rate limits per phone and per IP; connect the SMS gateway of your choice to send the codes.
• Notifications. Order-status push notifications to customers go through Firebase Cloud Messaging with your Firebase project. Transactional email needs your SMTP or email provider.

Realistic costs and timeline to launch

Every market and city tier prices differently, so treat the numbers below as illustrative ranges to plan against, not quotes:

• Dark-store setup (per store). Lease deposit, racking, cold storage and basic renovation: illustrative range ₹8-20 lakh.
• Initial inventory. First stock fill across 1,500+ SKUs: illustrative range ₹10-25 lakh per store.
• Technology. Ready-made platform source code versus custom development: illustrative range ₹3-15 lakh one-time for a ready-made platform, versus ₹40 lakh-1 crore-plus and 6-12 months for a custom build.
• Marketing and launch. Hyperlocal acquisition across your first pincodes: illustrative range ₹3-8 lakh for a launch quarter.

On a realistic timeline, the operational groundwork (securing a store, locking first inventory tie-ups, hiring riders, clearing FSSAI and Legal Metrology paperwork) takes most founders 6-10 weeks. The technology timeline is the one variable entirely within your control: build from scratch and you are looking at months of engineering before your first test order; license a ready-made platform and that same step shrinks to configuring stores, fees and branding.

Your edge in quick commerce is operational: the dark-store location you have secured, the distributor relationships you have built, the neighbourhood you understand better than any outside investor ever will. None of that edge comes from writing checkout code, and every week spent doing so is a week a local competitor could be taking your first customers. If you would like to see the whole platform running before you commit, get in touch for a walkthrough of the customer app, rider app, store dashboard and admin panel.

Frequently asked questions

Related reading