How to build an app like Swiggy: Architecture, dark stores, and what makes it hard

Swiggy's original pitch was simple: consistent, trackable food delivery in Bangalore. In 2014, when they launched, most restaurants delivered using their own staff, and you couldn't track your order -- you just waited and hoped.

They built three apps (customer, restaurant, delivery partner), a dispatch engine to connect them, and real-time order tracking. That's still the core of every food delivery platform today.

What's changed is everything on top: Instamart changed delivery from food to "anything in 10-30 minutes." Swiggy One (their subscription) changed the economics. Cloud kitchens changed who can be a restaurant. But strip it back, and the foundation is the same three-app system.

If you're building in this space, understanding that foundation -- and where the real technical difficulty lives -- is what separates projects that ship from projects that run over budget and never launch.

The three-app system and why each one matters

A common mistake: treating the customer app as the product and the restaurant/delivery apps as afterthoughts.

The restaurant app determines whether restaurants accept and confirm orders fast enough to keep food fresh. If confirming an order requires 5 taps in a confusing UI, restaurants confirm slowly, customers wait, and your delivery time stats suffer.

The delivery partner app determines whether delivery partners can earn enough to stay active on your platform. If navigating to a pickup, managing multiple orders, or logging earnings requires constant friction, delivery partners take fewer orders and mark themselves offline more often. Supply drops. Wait times climb. Customers churn.

All three apps need to be genuinely good for the platform to work.

Customer app

Restaurant discovery and search

The customer opens the app and sees restaurants nearby. The core display is a feed filtered by cuisine, dietary preference (vegetarian, vegan), price range, estimated delivery time, and rating. Sorting by rating, delivery time, or popularity are all standard.

Search by restaurant name or dish is surprisingly hard to do well. A customer typing "biryani" should see both restaurants named after biryani and every restaurant with biryani on their menu. This requires menu-level search indexing, not just restaurant-level.

Cart and ordering

Adding items to a cart from multiple restaurants creates a cross-restaurant cart problem. Most platforms enforce single-restaurant carts. The user picks one restaurant, builds a cart, and checks out.

Customizations (add extra cheese, no onions, extra spicy) need to be captured per item and transmitted to the restaurant clearly. This sounds simple but creates schema complexity -- customizations vary by restaurant and item, can have price implications, and need to render correctly in the restaurant app.

Real-time order tracking

Once an order is placed, the customer sees a live status screen: Order Received > Restaurant Confirmed > Being Prepared > Delivery Partner Assigned > Picked Up > On the Way > Delivered. Each state update pushes a notification.

The map showing the delivery partner's live location is the product moment that builds trust. It's also technically non-trivial -- you need the delivery partner app broadcasting location via WebSocket or Firebase Realtime Database, and the customer app rendering a moving map marker in real time.

Payment

Online payment (UPI, cards, digital wallets in India; cards, Apple Pay, Google Pay in other markets) plus cash on delivery. Multi-method checkout with saved cards. Order total breakdown (item cost + delivery fee + platform fee + taxes - any promo discount). Auto-apply loyalty credits if you have a subscription.

Restaurant partner app

Order management

When a new order arrives, the restaurant app plays a loud alert and shows the order details: items, customizations, delivery address (zone level, not exact address until confirmed), and customer notes.

Restaurants confirm the order (accepting it) and then update with a prep time estimate ("ready in 20 minutes"). This prep time feeds directly into the dispatch engine -- it uses the restaurant's estimated ready time to decide when to dispatch a delivery partner.

If confirmation takes more than 2-3 minutes, customers start cancelling. The alert needs to be impossible to miss.

Menu management

Restaurants need to mark items as available or unavailable in real time (if they run out of a dish). An order for an unavailable item causes a cancellation, a refund, and an angry customer. Real-time menu availability sync -- between the restaurant app and the search index -- is a solved problem but requires deliberate architecture (a menu update should propagate to the customer-facing catalog within seconds).

Scheduling items for availability (breakfast items only from 7-11am, lunch from 12-3pm) is a common restaurant requirement. Build it into the menu management system early.

Earnings and payouts

Restaurants see total revenue by day/week/month, order-level breakdowns, and pending platform payouts. Weekly automated payouts minus platform commission (typically 15-30% for food delivery platforms) are standard.

Delivery partner app

Job acceptance

When a delivery partner is assigned an order, they get a ping with pickup restaurant, estimated earnings for the job, and delivery zone. They accept or decline. If they decline, the dispatch engine assigns to the next eligible partner.

Acceptance rates are tracked. Partners who decline too often get fewer job offers -- this incentivizes staying active without forcing acceptance.

Navigation

Turn-by-turn navigation from the delivery partner's current location to the restaurant, then to the customer. Google Maps SDK or Mapbox provides routing. The app needs to deep-link to native Maps for real navigation on lower-end Android devices (common in India).

Multi-order batching

Advanced dispatch assigns multiple orders to one delivery partner if the pickup restaurants are close and the deliveries are in the same direction. This improves delivery partner earnings (more deliveries per hour) but adds complexity to the app -- the partner is juggling two pickup locations and two delivery addresses simultaneously.

Earnings and payouts

Real-time running earnings by day and week. Per-order breakdown. Daily/weekly payout to bank account. Incentive tracking -- platforms often run per-hour or per-order incentives to ensure partner supply during peak times.

The dispatch engine

The dispatch engine is where your operational efficiency is won or lost. It answers one question repeatedly: which delivery partner should pick up this order?

Basic dispatch: nearest available

The simplest implementation: when an order is confirmed by the restaurant, find the delivery partners who are active (online, not on another delivery) and within a radius, rank by distance, send a job offer to the closest one. If they don't accept within 30 seconds, try the next closest.

This works at small scale. It breaks at scale because it doesn't account for prep time -- you might send a partner to wait 15 minutes at a restaurant when a partner 500 meters farther away could arrive exactly when the food is ready.

Prep-time-aware dispatch

Better dispatch waits until the restaurant's estimated ready time is approaching before assigning a partner. The system calculates: "Restaurant says food ready in 18 minutes. The nearest available partner is 8 minutes away. Hold off on assignment for 10 minutes, then assign."

This requires reliable ready-time estimates from restaurants. Restaurants who consistently over- or under-estimate get their estimates adjusted downward or upward algorithmically.

Batching logic

Multi-order batching -- assigning two nearby orders to one partner -- improves partner earnings but increases customer delivery time. You need to define a "max combined delivery time" threshold. If batching an order would push delivery time over threshold, don't batch. This is a business policy decision embedded in the dispatch logic.

Delivery partner supply management

During peak hours (lunch 12-2pm, dinner 7-9pm), you need more delivery partners than off-peak. Platforms run "surge" incentives (bonus per delivery during peak hours) to pull partners online. The incentive logic -- when to trigger, how much to offer, which zones -- is part of the supply management system.

Quick commerce: Dark store architecture

Instamart (Swiggy's grocery delivery arm) is a different product from restaurant delivery. It's quick commerce -- 10-30 minute delivery of grocery and daily essentials.

The key difference: instead of partnering with restaurants, you own the inventory in small dark stores placed within delivery radius of customer demand.

Dark store requirements

A dark store is typically 1,500-3,000 sq ft, located in a commercial zone with vehicle access, stocked with 2,000-5,000 SKUs of groceries and daily essentials. It's not open to walk-in customers -- it's a fulfillment center.

From a tech perspective, a dark store requires:

Inventory management system (IMS)

Real-time SKU-level inventory tracking. When an item is picked for an order, inventory decrements immediately. Restock alerts trigger when inventory falls below threshold. Inbound stock reconciliation when new inventory arrives.

This is a warehouse management problem, not a delivery problem.

Picker app

When an order arrives at a dark store, a picker (staff member) receives a pick list in their app. Items are listed with bin/shelf location for efficient picking. The picker scans items to confirm (barcode scan or image recognition). Items not in stock can be substituted (if customer approved) or flagged for removal.

Pick time is a key operational metric -- most dark stores target 2-5 minutes per order.

Availability sync

If an item is out of stock, it needs to disappear from the customer-facing catalog within seconds. Stale inventory causes out-of-stock orders, substitution requests, and customer disappointment. The IMS and the product catalog need near-real-time sync.

Delivery dispatch for quick commerce

The dispatch logic for dark store delivery is simpler than restaurant delivery -- there's no prep time variable. When an order is picked and packed, it's ready immediately. The dispatch engine assigns the nearest available delivery partner.

But the delivery radius constraint is tighter -- promising 10-30 minute delivery only works if delivery partners are within 1-2 km of the dark store. You need controlled partner supply in the dark store zone.

Development timeline

For a single-city food delivery MVP (restaurant delivery, no quick commerce):

To add quick commerce (dark store): add 14-20 weeks for picker app, IMS, and inventory sync layer.

Cost summary

The supply-demand density lesson

Every food delivery platform that has failed did so for one of two reasons: it couldn't attract enough delivery partners to keep wait times acceptable, or it couldn't attract enough restaurants to give customers variety.

These aren't marketing problems. They're operational problems with geographic solutions.

Swiggy's launch strategy in Bangalore: sign up 6 restaurants and 20 delivery partners in Koramangala (a dense tech neighborhood). Get to 100 orders per day in that zone before touching any other area. That density -- enough restaurants that customers find variety, enough partners that wait times stay under 30 minutes -- is what makes the product work.

Pick a neighborhood, not a city. Fill it with supply before you expand. Your cost per order will be lower, your delivery times will be shorter, and your restaurant partners will see enough volume to stay committed.

1Raft builds food delivery platforms and marketplace apps for founders who understand the supply-demand piece isn't solved by technology alone. If you're scoping a food delivery or quick commerce product, one call maps what you actually need to build first.