Discovery & requirements
Mapped the three-sided model (customer, manager, courier), pinned down the late-delivery and address-confusion failure modes, and set the GDPR + CCPA posture and App Store / Google Play review requirements up front.
Case study · FoodTech · Mobile Marketplace
Food delivery aggregator — iOS, Android, and a routing engine
How we built a multi-vendor food-delivery aggregator for a FoodTech startup — native iOS and Android customer apps, a courier and manager admin panel, and a multi-modal routing engine that keeps deliveries on time across walking, bike, scooter, and car couriers. Architected for audiences across the United States and the European Union, with a GDPR- and CCPA-aligned, audit-ready posture from day one.
The brief — a delivery aggregator that ships on time
The FoodTech client came to YuSMP Group with a pointed operational problem: couriers were choosing suboptimal routes, taking unnecessary detours, getting confused by addresses, and burning time — which translated into late deliveries and eroded customer trust. The product vision was a single aggregator that unified restaurants, supermarkets, and pharmacies into one customer marketplace, while giving managers and couriers an operational back office that actually reduced delivery time rather than just recording it. The modern on-demand buyer in the United States and the European Union expects a clean catalog, a real-time order status, and an arrival window that holds — and the platform had to deliver all three across walking, bike, scooter, and car couriers in dense urban grids. We built it from first principles as a three-sided platform: native iOS and Android customer apps over a Laravel API, a React-based admin and dispatch surface for managers and couriers, and a multi-modal routing engine at the core that adapts the optimal path to each courier's transport mode. The build reached final pre-release testing across the US and EU app stores, with support scoped through publication and future updates.
Project highlights
Native iOS + Android customer apps
Multi-vendor marketplace catalog
Multi-modal courier routing engine
Real-time order status tracking
Laravel API control plane
React manager & courier admin
Cart, checkout & promotions
Pre-release testing live · US & EU
By the numbers
A snapshot of what the food-delivery aggregator build delivered across iOS, Android, a Laravel control plane, and a multi-modal routing engine.
2native customer platforms — iOS and Android, each optimized per platform over one shared API
4courier transport modes routed independently — walking, bike, scooter, and car profiles
3account roles in one ecosystem — customer, restaurant or store manager, and courier
~9 mobuild timeline to final pre-release testing across both app stores
2app stores targeted — Apple App Store and Google Play across US and EU storefronts
16–28 wktypical delivery window for a comparable aggregator MVP on both stores
Why a custom multi-modal routing engine over off-the-shelf maps
The routing decision dominates every other architectural choice in a delivery aggregator, because late deliveries were the exact failure the client hired us to fix. We chose a custom multi-modal routing layer over a single off-the-shelf directions API because the same map produces fundamentally different optimal routes for a walking courier, a bike, an e-scooter, and a car. Each mode gets its own speed profile and turn-cost model, and the dispatcher scores candidate couriers by estimated arrival time, current load, and mode suitability for the delivery distance — then continuously re-optimizes as new orders enter the queue. A raw consumer directions API, by contrast, assumes a single travel mode per request and has no concept of dispatch fairness or fleet load, so any honest on-time claim has to be reasoned about in our own layer. We use mapping providers for the underlying road and pedestrian graph and layer our scoring and dispatch logic on top, which keeps the routing engine portable across US and EU cities without rewriting the dispatcher.
Off-the-shelf white-label delivery SDKs were eliminated early: their dispatch heuristics are opaque, their travel-time models assume car-only fleets, and their licensing terms made the three-sided account model awkward. Building the routing engine ourselves on top of open standards meant the entire path — catalog, cart, dispatch, courier app — is one coherent, owned system, delivered as part of our custom software development practice.
| Dimension | Custom routing engine | Single-mode directions API | White-label delivery SDK |
|---|---|---|---|
| Transport modes | Walking, bike, scooter, car — separate profiles | One mode per request | Usually car-only fleet model |
| Dispatch fairness & load | Built into the scorer — ETA, load, mode fit | None — directions only | Opaque vendor heuristic |
| Re-optimization on new orders | Continuous via queued jobs | Manual re-query | Vendor-controlled |
| Three-sided account model | Native — customer, manager, courier | Not applicable | Awkward to extend |
| Portability across US & EU cities | High — swap the map graph, keep the dispatcher | High but logic-free | Region-locked licensing |
| Data ownership | Full — order and dispatch data in our plane | Queries leave to vendor | Vendor-held |
| Cost at scale | Predictable — per-graph-query only | Per-request, grows with re-queries | Per-order vendor fee |
Routing references: OpenStreetMap routing concepts, Apple MapKit documentation, Android location and maps reference.
iOS build — Swift, the marketplace, and the cart flow
The iOS customer app is built in Swift, with a marketplace home that collapses restaurants, stores, and pharmacies into one searchable surface, category chips, and a promo rail (the "first delivery free" banner is a merchandising slot driven from the admin). The product-detail and cart flow was where we spent disproportionate effort, because abandoned carts are where most delivery apps quietly leak revenue: the add-to-cart control, quantity stepper, and live order total update instantly without a network round-trip, and the cart reconciles against server pricing only at checkout. The catalog is cached locally so browsing stays fluid on flaky cellular networks, and the app degrades gracefully when a vendor goes offline mid-session.
Order placement hands off to the routing engine the moment a customer confirms: the backend resolves the delivery address, picks the lowest-ETA suitable courier, and pushes a live status the customer can watch from "accepted" through "on the way." The same Swift client carries the location-permission and notification flows in context — requested when the customer first tracks an order, never at cold launch — to satisfy App Store reviewers and to keep the consent experience honest for users in the US and EU. The end-to-end iOS surface is delivered as part of our mobile app development practice.
Android build — Kotlin, the vendor catalog, and real-time status
The Android customer app is written in Kotlin, sharing the same Laravel API as iOS but tuned for the fragmentation realities of the Android fleet. The vendor catalog renders as a fast, image-heavy grid with ratings, prep-time estimates, and prices, backed by paginated API calls and aggressive image caching so the list stays smooth on mid-range devices across Samsung, Xiaomi, and Pixel families. Cart state, favorites, and the active order survive process death and configuration changes — a real concern on Android, where aggressive battery optimizers and low-memory kills routinely tear down background app state.
Real-time order status is the contract the customer implicitly signs up for, so the Android client keeps a live channel to the backend for status transitions — accepted, preparing, picked up, on the way, delivered — and falls back to push notifications when the app is backgrounded. Location and notification permissions are requested in context, and the order-tracking screen reads from the same status pipeline that the courier app writes to, so customer and courier never see divergent state. The same engineering team carries iOS and Android in lockstep as part of our iOS and Android engineering practice.
Control plane, privacy posture, and audit-ready hardening
The control plane is a Laravel backend with a React admin and dispatch surface for restaurant and store managers and for couriers. Managers work a live order board — incoming orders, vendor acceptance, preparation timers — while couriers get a dispatch view with their assigned route, the next pickup, and the customer drop-off. Order events flow through a single state pipeline so customer, manager, and courier always read the same status, and routing and notification work runs as queued background jobs to keep the customer-facing apps responsive under load. Address handling, the exact pain the client raised, is normalized server-side and validated against the map graph before a courier is ever dispatched.
On privacy, the platform was architected to align with GDPR obligations for users in the European Union and CCPA / CPRA obligations for users in California and the broader United States. Customer location is collected only for the duration of an active order, payment identity is handled by the payment provider rather than stored in the order plane, and access to the admin surface is role-scoped so a courier never sees another courier's customer data. The design makes a future independent privacy readiness review a documentation exercise rather than an architectural retrofit.
Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.
Delivery methodology
A five-phase build that took the aggregator from product specification to final pre-release testing across iOS, Android, a Laravel control plane, and the routing engine.
Architecture & routing
Laravel API skeleton, multi-vendor catalog schema, the multi-modal routing engine with per-mode speed profiles, and the dispatch scorer for ETA, load, and mode fit.
Platform builds
Swift iOS and Kotlin Android customer apps over the shared API, plus the React manager and courier admin and dispatch surfaces, with cart, checkout, and real-time status.
Hardening & QA
Role-scoped access control, address normalization against the map graph, permission-flow QA, load testing of the dispatch queue, and audit-ready privacy posture verification.
Pre-release & support
Final pre-release testing ahead of App Store and Google Play submission across US and EU storefronts, with support scoped through publication and future updates.
The courier app, dispatch, and the operational back office
The courier-facing app and the manager dispatch console are where the platform actually earns its on-time promise. A courier signs in, sees a route assembled by the routing engine for their transport mode, and works a sequence of pickups and drop-offs with turn-by-turn guidance and one-tap status transitions — arrived, picked up, delivered — that write straight into the shared order pipeline. The dispatcher does not just assign the nearest courier; it scores candidates on estimated arrival time, current load, and whether a walking, bike, scooter, or car courier is the right tool for the delivery distance, then re-optimizes as fresh orders arrive so a single new order does not strand an already-efficient route. Managers, meanwhile, run a React order board that surfaces vendor acceptance, preparation timers, and any delivery running behind its window, with the address normalization that fixes the original confusion baked in before a courier is ever dispatched. The whole operational surface was built for extensibility: adding a new vendor type, a new transport mode, or a new city is a configuration and data exercise against the catalog and routing services, not a code release — the same scaling discipline we bring to our cloud & DevOps roadmaps.
Launching across the United States and the European Union
The aggregator was architected for App Store and Google Play storefronts across the United States and the European Union from a single codebase per platform. The English-language build is positioned for users in California, New York, Texas, Florida, and Washington in the US, and for users in the Netherlands, Germany, France, Ireland, and Sweden in the EU, without a separate codebase per region. Consent flows are region-aware at the client layer: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for optional product analytics, while users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure in the same flow. Data-handling practices are aligned with GDPR for European Union users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA. Because customer location and order data are minimized and short-lived by design, regional compliance reduces largely to honest disclosure rather than per-jurisdiction data segregation.
The routing engine is portable across US and EU cities by design — the dispatcher and per-mode speed profiles stay constant while the underlying map graph is swapped per region, citing GDPR obligations and California CCPA obligations directly in the in-app privacy policy. Both the App Store age rating and the Google Play content rating were calibrated for a food-and-drink delivery feature set, and location and notification permissions are requested in context to satisfy reviewers in both the US and EU. The engineering team behind the build sits across CET and runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and incident response — the timezone window that lets a US product team and an EU engineering team share four hours of live overlap every day.
Tech stack and roadmap
Swift
SwiftUI
Kotlin
Jetpack Compose
Laravel
PHP
React
TypeScript
PostgreSQL
Redis
Laravel Queues
WebSockets
Push Notifications
MapKit / OSM
Routing Engine
Docker
Kubernetes
Terraform
Prometheus
The active custom software development roadmap for the aggregator includes scheduled and group ordering, a loyalty and promotions engine on top of the existing merchandising slots, courier earnings and shift management in the dispatch console, and live map tracking of the courier on the customer's order screen. Infrastructure plans include further dispatch-queue automation, multi-city rollout tooling so a new region is a data exercise, and a data-residency option that pins EU and US order data to regional storage — all scaffolded into the cloud & DevOps roadmap so the platform scales cleanly from one city to a national footprint across the US and EU.
Build a delivery aggregator like this — talk to us
If you are planning a food-delivery aggregator, a q-commerce app, or any on-demand logistics product where the on-time promise has to survive real urban dispatch for audiences in the US and EU, we have shipped this stack end-to-end and can compress the build timeline meaningfully. The platform reached final pre-release testing across iOS and Android, and the engineering team behind it sits inside YuSMP Group. You can see the build at a glance in our food-delivery aggregator case study. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.
Frequently asked questions
How much does it cost to build a food-delivery aggregator app like Uber Eats or Wolt?
A food-delivery aggregator MVP covering customer iOS and Android apps, a multi-vendor catalog, cart and checkout, and a basic courier and manager admin panel typically costs $90k–$220k. Adding a multi-modal courier routing engine, real-time tracking, payment integrations, promotions, and a separate courier app brings a full marketplace to $250k–$550k. The dominant cost drivers are the routing and dispatch logic, the three-sided account model, and the real-time order-state synchronization across customer, vendor, and courier surfaces.
Why use Laravel and React for a delivery marketplace backend?
Laravel gives a delivery marketplace a mature, batteries-included PHP backend — queues for dispatch jobs, an expressive ORM for the multi-vendor catalog, and a large hiring pool that keeps a three-sided platform maintainable. React powers the manager and courier admin surfaces with a component model that maps cleanly onto live order boards and dispatch consoles. The pairing keeps the API and the operational web tooling in one well-understood ecosystem, which shortens the build and lowers long-term ownership cost for the US and EU teams that run the platform.
How do you build a courier routing engine for multiple transport modes?
A multi-modal routing engine separates the travel-time model from the dispatch logic. Each transport mode — walking, bike, scooter, and car — gets its own speed profile and turn-cost model, so the same map produces different optimal routes per courier. The dispatcher scores candidate couriers by estimated time of arrival, current load, and mode suitability for the delivery distance, then assigns and continuously re-optimizes as new orders arrive. Routing calls run as queued background jobs so the customer-facing app stays responsive.
What are the App Store and Google Play rules for food-delivery apps?
Apple and Google both require food-delivery apps to disclose data collection clearly, handle location permission with a foreground-use justification, and route in-app digital purchases appropriately while allowing real-world delivery to be paid outside in-app purchase. Both stores expect a working privacy policy, age-appropriate content ratings, and — for apps serving EU and California users — a granular consent flow that satisfies GDPR and CCPA / CPRA in the same screen. Location and notification permissions must be requested in context, not at first launch.
How long does it take to ship a food-delivery aggregator on iOS and Android?
A focused MVP with customer iOS and Android apps, a multi-vendor catalog, cart and checkout, and a basic admin panel typically takes 16–28 weeks. Adding a multi-modal courier routing engine, a dedicated courier app, real-time tracking, and payment and promotion subsystems adds 8–14 weeks. This aligned with the roughly nine-month timeline of this build, which reached final pre-release testing across both stores with ongoing support scoped through publication and future updates.
Related cases
More delivery & consumer marketplace builds
FoodTech · Grocery delivery
Grocery Delivery
On-demand grocery marketplace with a courier app, ops console, and live order tracking across US & EU.
View case → FoodTech · NutritionBasilDoc
Meal-plan and diet-recommender platform pairing recipes with delivery for health-conscious US & EU users.
View case → Consumer · MobileLiMP VPN
Native iOS + Android consumer app with a hardened control plane and audit-ready posture across US & EU.
View case →Related services
Mobile App Development
Native iOS, Android, and cross-platform apps with store-ready release pipelines.
Explore mobile app development →
Custom Software Development
Custom platforms engineered to your business model, scaling cleanly from MVP to millions of users.
Explore custom software development →
Cloud & DevOps
Scalable infrastructure, CI/CD pipelines, and observability so your platform grows from one city to a national footprint.
Explore cloud & DevOps →