Food Delivery

Pickup or delivery is the scope decision that sizes everything else

A food ordering app with delivery is four products: the customer app, the restaurant app, a courier app, and an admin portal that also runs dispatch. Pickup removes the third product, and most of what makes delivery hard to ship.

• No courier app. No driver onboarding, document checks or shift availability.
• No dispatch. Nothing decides which driver takes which order, or reassigns it when one declines.
• No live driver tracking. Background location on a courier's phone is the part of on-demand apps that behaves worst in the field.
• No courier payouts. No ledger of what each driver is owed, and no disputes about it.

What pickup costs you is reach. The customer has to be willing to travel, so the product only works where restaurants are close to the people ordering. This platform is pickup, so it is three products, not four. If couriers are part of your plan, that is on-demand app development layered on an order flow you still have to get right first.

Three products, and the restaurant app decides whether orders get fulfilled

• The user app. Nearby restaurants with ratings and reviews, a cart, order placement, online payment through HyperPay, real-time tracking of traffic and food preparation time, and pickup from the restaurant.
• The restaurant app. Manage orders, the menu and revenue.
• The admin portal. Add, edit and delete restaurants; a list of users with their order history; add, edit and delete VAT; add, edit and delete subscription packages for restaurants; a revenue and statistics dashboard.

The apps are native, Java for Android and Swift for iOS, on a Laravel backend with MySQL on AWS and an SMS gateway.

Most design time goes into the user app. The restaurant app is the one that decides whether a paid order turns into food. It is used during a rush, often on a shared device. Three things in it matter most:

• Order acceptance. An unacknowledged order is a customer waiting at a counter with a receipt. Build an explicit accept step, an alert that repeats until someone taps it, and an automatic cancel and refund if nobody does within a set window.
• Preparation time. The kitchen knows it is overloaded tonight; the platform does not. Let staff set or adjust the estimate per order.
• Menu availability. Marking an item sold out should take one tap and reach the user app at once. Otherwise customers pay for food the restaurant cannot make.

Timing the pickup means estimating two clocks, not one

Ordering ahead promises food that is ready when the customer walks in. That depends on two estimates: how long the kitchen needs, and how long the customer needs to get there. This platform tracks both, food preparation time and traffic.

When either is wrong, the failure shows up at the counter:

• Preparation runs long. The customer waits in a restaurant with no seat for them, and blames the app.
• Preparation runs short. The food sits and goes cold, and the customer who planned ahead gets a worse meal than someone who walked in.
• Travel runs long. Cold food again, and an order that may never be collected.

Show the kitchen the customer's estimated arrival, so staff start a dish when it makes sense rather than the moment the order lands. Show the customer the preparation estimate and when it was last updated. And decide what happens to an order nobody collects: who keeps the payment and how long it is held. That is policy, but it needs an order state and an admin screen either way.

Subscription, commission or hybrid: pick the revenue model before the schema

On this platform, the admin portal adds, edits and deletes subscription packages for restaurants. The more familiar model is a commission on each order. They pull the build and the sales pitch in different directions.

Model	Who carries the risk	Effect on restaurant sign-up	What you must build
Per-order commission	The platform: no orders, no revenue	Easy to say yes to, nothing up front; resentment grows with volume	Commission rules per restaurant, deduction at settlement, statements a restaurant can reconcile
Subscription	The restaurant: it pays whether orders come or not	Harder to say yes to, especially before the app has customers	Package definitions, billing cycles, renewals, and what a lapsed restaurant can still do
Hybrid (smaller fee plus smaller commission)	Shared	A middle ground, with more to explain	Both of the above, plus the rules for which applies when

Whichever you choose, store the terms as data on the restaurant and copy them onto each order when it is placed. A restaurant that changes package mid-month, or a rate that changes next quarter, must not rewrite orders already settled. If customers pay the platform, money also has to reach each restaurant, which is the core problem in multi-vendor marketplace development.

Payments and VAT belong in configuration, not in code

Online payment here goes through HyperPay, a regional payment gateway, rather than a global default. For a single-market product, ask which payment methods customers there actually use before asking which gateway has the nicest SDK.

VAT on this platform is managed in the admin portal, where it can be added, edited and deleted. That is the right shape. Tax rules change, and a rate compiled into two native apps means a release through two app stores before receipts are correct. Keep the rate on the server, record the rate applied on each order, and never recalculate an old order with today's number.

Refunds and cancellations need a plan for:

• a cancellation before the restaurant accepts, which should refund in full without anyone touching it;
• a cancellation after the kitchen has started, which is a policy you want written down before launch;
• partial refunds when one item turns out to be unavailable;
• gateway callbacks that arrive late, twice or not at all, so every payment state change is idempotent and checked against the gateway's own records.

The order and the payment are two state machines that have to agree. Payment software development is mostly the work of keeping them in step.

Maps: store the restaurants, compute the journey

Nearby-restaurant search and distance on this platform use the MapBox API. The split that keeps latency and the map bill sensible:

• Store and index yourself: restaurant coordinates, opening hours, and whether each restaurant is accepting orders right now. Finding nearby restaurants is a geospatial query against your own database, not a map API call per restaurant.
• Compute at request time: the travel estimate from the customer's current position, because it depends on live traffic and changes as they move.
• Cache briefly: travel estimates for the same origin and restaurant over a short window, and map tiles on the device.

Location permission deserves its own design. A customer who declines it still needs a way to search by area, or the first screen of the app is empty.

What a restaurant ordering platform costs, and how to scope one

A platform where many restaurants sell through one app is a multi-vendor marketplace, and it sits in our published marketplace band of $15,000 to $150,000+. At a blended rate of about $20 per hour, the arithmetic is team-weeks:

• Illustrative, not a quote: four people for twelve weeks at 40 hours a week is 1,920 hours, about $38,400.
• Illustrative, not a quote: five people for twenty weeks is 4,000 hours, about $80,000.

What moves a build along that band: native apps on both platforms rather than one cross-platform codebase, delivery rather than pickup, the revenue model and its settlement, and how much of the admin portal has to exist on day one. The mobile app development cost guide covers the drivers on the app side.

If your scope is still a list of screens, a Scoping Sprint turns it into a clickable prototype, a technical plan and a fixed quote: $2,300 fixed, two weeks, credited in full if we build it.

A single restaurant should not build one of these

If you run one restaurant or a small chain, do not start here. Existing online ordering products and aggregator apps already have the customers and the payment integrations; a custom app has neither on day one. Few people will install an app to order from one restaurant.

A custom platform makes sense when you are the marketplace: many restaurants, your own brand, your own revenue model, or a market the existing platforms serve badly. Even then, sign the restaurants before the customers arrive. An ordering app with six restaurants in it is an app nobody opens twice.

---

Planning a multi-restaurant ordering app and not sure whether pickup, delivery or both belongs in the first release? A Scoping Sprint ($2,300, two weeks) ends with the product split and revenue model made for your case, a prototype, and a fixed quote. Or just start a conversation.