Developing a Mobile App for Food Delivery
Food delivery technically resembles taxi: geolocation, live tracking, payment gateway. But significant differences—menu with variants and modifiers, restaurant logic with schedule and stops, preparation time as separate delivery calculation variable, delivery zones with distance-based pricing.
Three System Types
Aggregator (Delivery Club model)—many restaurants, shared courier pool, client chooses from multiple venues. Complex dispatch, API for restaurant onboarding, own courier fleet or outsourcing.
Restaurant's own delivery—one restaurant or chain, own couriers. Simpler architecture, but need admin panel for restaurant manager.
White-label platform—aggregator architecture but for specific restaurant or small chain. Middle ground.
Most startups initially choose second or third. Aggregator requires separate product for partner onboarding, doubles work.
Menu and Cart
Restaurant menu—not just dish list. Categories, subcategories, dishes with variants (pizza size, doneness, toppings). Support modifiers: "add cheese +80₽", "choose sauce" (mandatory single choice), "remove onion" (optional).
{
"id": 42,
"name": "Pizza Margherita",
"base_price": 590,
"modifier_groups": [
{
"id": 1,
"name": "Size",
"required": true,
"min_select": 1,
"max_select": 1,
"options": [
{"id": 11, "name": "25 cm", "price_delta": 0},
{"id": 12, "name": "35 cm", "price_delta": 150}
]
},
{
"id": 2,
"name": "Extra",
"required": false,
"max_select": 3,
"options": [
{"id": 21, "name": "Double cheese", "price_delta": 80},
{"id": 22, "name": "Hot pepper", "price_delta": 0}
]
}
]
}
Client cart logic: each item stores base product_id + selected modifier_ids. Price calculated client-side for display, server-side for final order. Cart persists locally on app close.
Delivery Zones and Minimum Order
Restaurant doesn't deliver everywhere with different prices. Zones defined by polygons, not circles. On address input, check polygon containment: client-side check (Google Maps containsLocation(point, polygon) or turf.js port to Dart/Swift/Kotlin) for fast UX, server-side for final arbitration on order creation.
PostGIS on server: ST_Contains(zone.polygon, ST_MakePoint(:lon, :lat))—reliable and accurate.
Each zone—separate database row with delivery cost and minimum order. If address matches no zone—show "We don't deliver to your area yet."
Preparation and Delivery Time
User wants: "when ready and when delivery arrives". Preparation time—restaurant parameter, may vary by load. Admin sets current time in control panel. Delivery time—estimated from distance and courier speed.
Display: "~45 minutes" (prep 25 + delivery 20). Don't promise exact time without real dispatcher integration.
Order Statuses and Tracking
Food delivery statuses more complex than taxi:
placed → confirmed → preparing → ready_for_pickup → courier_assigned → courier_picked_up → delivering → delivered
Client sees simplified: "Accepted" → "Preparing" → "In transit" → "Delivered". Between "In transit" and "Delivered"—courier tracking on map (same WebSocket + animated marker).
Push notifications on each status change. Firebase Cloud Messaging, data notifications for background processing, notification for display. iOS—UNNotificationContent with category ORDER_UPDATE, Android—dedicated NotificationChannel.
Payment
Online payment (CloudPayments / YooKassa / Tinkoff Acquiring) + cash on delivery + Apple Pay / Google Pay. Pre-authorization (hold)—standard for delivery: amount held on order creation, charged on confirmation. If restaurant rejects—hold auto-released.
Promo codes and loyalty—separate module. Applied on order confirmation, discount calculated server-side.
Restaurant Admin App
Without it system doesn't work in production. Minimum screens:
- Current orders (list with timers, statuses)
- Stop management (button "item out of stock")
- Current prep time (input field, applied immediately)
- Work schedule
Can be web panel initially, not necessary mobile app.
Stack
| Component | Technologies |
|---|---|
| iOS client | Swift, UIKit/SwiftUI, GoogleMaps SDK, CloudPayments |
| Android client | Kotlin, Jetpack Compose, Google Maps SDK |
| Flutter | Dart, flutter_bloc, google_maps_flutter |
| Backend | Node.js / Laravel / Django, WebSocket, PostgreSQL + PostGIS, Redis |
| Notifications | Firebase Cloud Messaging |
Timeline
MVP (one platform, one restaurant, basic tracking): eight-twelve weeks.
Full platform (iOS + Android, restaurant panel, multi-venue aggregator, analytics): five-eight months.
Cost estimated individually after requirement analysis and task decomposition.