We are a mobile development team with extensive experience in foodtech. Over that time, we have delivered 20+ projects — from single-restaurant apps to full-scale aggregators with hundreds of venues. According to our data, 70% of users expect real-time tracking, and its absence increases support load by 30–40%. We embed these nuances into the architecture from day one.
Food delivery is technically similar to ride-hailing: geolocation, real-time tracking, payment gateway. But there are significant differences — a menu catalog with options and modifiers, restaurant logic with schedules and stop-lists, preparation time as a separate variable in delivery ETA, and delivery zones with varying prices based on distance. On average, a restaurant processes 150–300 orders per day, with peak load reaching 50 orders per minute.
Get a free project estimate in 2–3 days. Discuss your task with our engineers — they will help you choose the optimal architecture.
Architecture and Key Modules
Which Architecture Suits Your Business?
We develop three architectural approaches to fit any budget.
Aggregator (like Delivery Club) — many restaurants, a shared pool of couriers, the customer chooses from multiple venues. Complex dispatching, API for restaurant onboarding, own courier fleet or outsourcing. Development timeline: from 5 months.
Restaurant's own delivery — one restaurant or chain, own couriers. Architecturally simpler, but an admin panel for the restaurant manager is needed. MVP: from 8 weeks.
White-label platform — same architecture as the aggregator, but tailored for a specific restaurant or small chain. A middle ground.
| Criteria | Aggregator | Own Delivery | White-label |
|---|---|---|---|
| Number of restaurants | Many (10+) | One or chain | One or small chain |
| Couriers | Shared pool | Only own | Only own |
| Dispatching complexity | High | Low | Medium |
| Time to launch (MVP) | From 5 months | From 8 weeks | From 3 months |
Menu and Cart
A restaurant menu is not just a list of dishes. Categories, subcategories, items with options (pizza size, doneness, extras). The data structure must support modifiers: "add cheese +80₽", "choose sauce" (required single choice), "remove onion" (optional). The number of modifiers per dish can reach 10, and conversion after selecting items is 65%.
{ "id": 42, "name": "Margherita Pizza", "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": "Extras", "required": false, "max_select": 3, "options": [ {"id": 21, "name": "Extra cheese", "price_delta": 80}, {"id": 22, "name": "Chili", "price_delta": 0} ] } ] } Cart logic on the client: each line item stores the base product_id plus selected modifier_ids. The price is calculated client-side for display, and server-side for the final order. The cart is saved locally when the app is closed.
Why Is Server-Side Validation of Delivery Zones Important?
A restaurant does not deliver everywhere, and prices vary by zone. Zones are defined by polygons — not simple circles. When the user enters a delivery address, we check if it falls within a polygon: client-side check (via Google Maps containsLocation(point, polygon) or a port of turf.js in Dart/Swift/Kotlin) for quick UX, and server-side check as the final arbiter when creating the order.
PostGIS on the server: ST_Contains(zone.polygon, ST_MakePoint(:lon, :lat)) — reliable and accurate. PostGIS is 10x better than client-side geo libraries and ensures data consistency.
Each zone is a separate row in the table with its own delivery fee and minimum order. If the address does not fall into any zone, we show the message: "Unfortunately, we do not deliver to your area yet."
Order Time and Statuses
The user wants to know: "when will it be ready and when will it arrive?" Preparation time is a restaurant parameter that can vary based on load. The admin sets the current time in the control panel. Delivery time is estimated based on distance and courier speed. Average delivery time in a zone is 15–30 minutes. Final display: "~45 min" (cooking 25 + delivery 20). Avoid promising exact time without integration with a real dispatcher.
| Client Status | Internal Status | Description |
|---|---|---|
| Accepted | confirmed | Order confirmed by restaurant |
| Preparing | preparing | Restaurant started cooking |
| On the way | delivering | Courier picked up and is moving |
| Delivered | delivered | Order handed to customer |
Push notifications on every status transition. Firebase Cloud Messaging — data notifications for background processing, notification for display. On iOS — UNNotificationContent with category ORDER_UPDATE, on Android — a dedicated NotificationChannel.
How Does Courier Tracking Reduce Support Load?
Without real-time tracking, users call support — each call costs the restaurant an average of 50₽. An app with a map and animation reduces call center load by 30–40% and increases NPS by 15 points.
Payment Gateway
Online payments (CloudPayments / YooKassa / Tinkoff Acquiring) + cash on delivery + Apple Pay / Google Pay. Pre-authorization (hold) is standard practice for delivery: the amount is held when the order is created, captured when confirmed. If the restaurant does not accept the order, the hold is automatically released. Promo codes and loyalty system — a separate module. Applied at the order confirmation stage, discount calculated server-side.
Restaurant Admin App
Without it, the system cannot work in production. Minimal set of screens:
- Current orders (list with timers, statuses)
- Stop-list management (button "item out of stock")
- Current preparation time (input field, applied immediately)
- Operating hours
It can be a web panel — not necessarily a mobile app for the first stage.
How We Develop? Step-by-Step Plan
- Analysis — study business processes, delivery zones, menu requirements. Document in a technical specification.
- Design — create architecture (ERD, flow diagrams), define the tech stack.
- UI/UX Design — produce mockups adhering to platform guidelines.
- Development — 2-week sprints, daily demos to the client.
- Testing — unit, integration, UI, load testing (up to 1000 orders/min).
- Deployment — publish to App Store and Google Play, set up CI/CD.
- Support — bug fixes, warranty improvements.
What's Included
Upon project completion, we deliver:
- Source code of the app (iOS/Android/Flutter)
- API documentation (Swagger/OpenAPI)
- Backend deployment instructions
- Access to App Store Connect and Google Play Console
- Restaurant admin panel
- Team training (2–3 hours)
- 3-month code warranty
Get a free consultation for your project. Contact our engineers — we'll discuss the details.
Checklist of Typical Development Mistakes
- Ignoring modifiers in the menu structure — leads to limitations when expanding the assortment.
- Lack of server-side validation of delivery zones — the client may see unavailable addresses.
- Flat notification architecture — confusion about statuses, user doesn't understand what's happening.
- Not factoring preparation time into ETA — the customer receives the order later than promised.