Food delivery app development: how to build one for restaurants and what it costs

Food delivery app development means building the software that moves an order from customer to kitchen to door. A full system for one brand has customer and kitchen apps, an admin panel, a courier app for your own couriers, and a shared backend. It starts from $30,000 and takes at least 8 weeks. If you already run an ordering system, a customer app connected to it costs from $5,000. The hard part is time: hot food must leave the kitchen when the courier arrives.

Restaurant owners, delivery-only kitchens, and founders can use this guide to understand the work before they ask for quotes. Our logistics software development page describes the service we offer for this work.

Types of food delivery apps

The types differ by who cooks the food and who delivers it, and that shapes the backend. Pick the type first, because the same customer screens can sit on top of very different systems.

Grocery delivery is a different product: longer baskets, stock that changes during the day, and items priced by weight. Our grocery delivery app guide covers that case. A marketplace is also more than a restaurant app with more restaurants in it. Our marketplace development page covers the partner side.

“When a restaurant weighs its own app against a marketplace, the question is who keeps the customer. Delivery platforms are good at finding new customers and bad at keeping them for you, because the customer belongs to the platform. With your own app, you keep the people who already love your food, their order history, and a direct way to reach them.”

Roman Surikov, CEO at Ronas IT

Business models for food delivery apps

The app can earn money from restaurants, from customers, or from both, and the model you choose changes the backend. Choose one main model for the launch and add others later.

• Commission: the marketplace takes a share of each order from the restaurant. The backend splits the payment and pays restaurants on a schedule.
• Delivery fee: the customer pays for delivery, for example by distance or by demand. The backend calculates the fee before checkout.
• Subscription: customers pay monthly for free delivery or discounts, which rewards frequent orders. The backend needs billing, and the app applies the benefit at checkout.
• Promoted listings: restaurants pay to appear higher in search, which needs an app that already has enough customers.

A restaurant brand with its own app sells its own food, so it has no commission to take. It can charge a delivery fee or offer a subscription, and orders placed in the app carry no marketplace commission.

Key features of a food delivery app, by role

Four roles need their own features: customers who order, the kitchen that cooks, couriers who deliver, and the operators who run the admin panel. In a full system, all four work on the same order in one backend, which also keeps the menu, the payment, and the courier positions. A restaurant that delivers through a provider can drop the courier app, and one that already runs an ordering system may need only the customer app, connected to that system.

Customer app

• Search and menus: restaurants or dishes by cuisine, distance, and delivery time, with photos and prices.
• Order options: add-ons, notes for the kitchen, and allergy information for each dish.
• Checkout: address, delivery or pickup, a delivery time, tips, and payment.
• Tracking: the order status, and the courier on a map once the food is on its way.
• Repeat orders and ratings: order history, reorder in one step, and a rating after delivery.

Kitchen side

• Order queue: new orders with a sound alert, accept or reject, and a preparation time for each order.
• Menu control: mark a dish as sold out, change prices, and pause the restaurant when the kitchen is overloaded.
• Handoff: mark the order as ready and see which courier will pick it up.

In a small restaurant this can be a tablet app. In a chain, orders can go straight into the point-of-sale system the kitchen already uses.

Courier app

• Offers: accept or decline a delivery, with the pickup point and the distance.
• Navigation and status: the route, arrival at the restaurant, pickup, and delivery.
• Handoff proof: a photo or a code for contactless delivery.
• Shifts and earnings: availability, completed deliveries, and tips.

Admin panel

• Operations: live orders, late orders, couriers on the map, and manual reassignment.
• Settings: delivery zones, fees, opening hours, and promo codes.
• Money: refunds, commissions, and payouts to restaurants and couriers.

Challenges specific to restaurant delivery

A food order has a short life: it is cooked to order, it gets cold, and orders come in peaks around lunch and dinner. The four problems below each need their own logic in the backend; the screens are the easy part.

Kitchen time and courier arrival

If the courier arrives too early, they wait and lose money. If they arrive late, the food waits and gets cold. So dispatch, the logic that assigns couriers, uses the preparation time the kitchen sets for each order. The system starts looking for a courier when the travel time to the restaurant matches the time left in the kitchen. The kitchen can change its estimate, and the dispatch moves with it.

“When I design a delivery system, I start with the order states and their timers on the server, and the apps only show those states. If a courier loses signal or an order is not ready on time, the server still knows what should happen next.”

Evgeny Leonov, CTO at Ronas IT

Menus and sold-out dishes

A dish that sells out at 8 p.m. has to disappear from the app within minutes, or the kitchen starts calling customers. Decide which system owns the menu: the POS, your admin panel, or a menu service. The app then reads from that one source, and the kitchen can mark a dish as sold out in one tap. If several systems hold the same data, our article on logistics API integration explains how to pick the one that owns each record.

Lunch and dinner peaks

Load arrives in two short waves, so the system has to handle peak hours, not the daily average. In practice this means an order queue on the server, live updates pushed to the apps over an open WebSocket connection instead of constant refreshing, and a way for the kitchen to pause new orders. Courier supply matters as much: the admin panel should show when orders wait for a courier, so the team can widen the delivery time or the zone.

Own couriers or a delivery provider

Your own couriers need a courier app, shifts, dispatch, and payouts. A delivery provider replaces all of that with an API. With Uber Direct, your app calls the Create Delivery endpoint and Uber sends a courier to collect the order from the store and deliver it to the customer. Providers set their own access rules and pilot steps, so confirm production access before you design around one.

Noah and ShipMe: related projects we built

Two of our projects cover parts of the system described earlier: Noah, a food marketplace with delivery and pickup, and ShipMe, a delivery platform where each order moved through a chain of statuses. Neither is a restaurant delivery app, so the challenges section above describes our general practice, and each project below proves only its own part.

Noah: local food from producers to customers

Noah was a farmer marketplace from Sweden that connected local food producers with consumers and charged commissions on purchases. We designed and built consumer apps for iOS and Android, a mobile producer app, and a web admin panel within four months, before the harvest season.

• Delivery or pickup: customers saw producers on a map with the distance, which told them how quick delivery would be, and chose delivery or pickup at checkout.
• A seller app on the phone: producers managed their profiles, products, orders, and promo codes from a mobile app, because they sometimes could not spend much time at a computer.
• Ratings in search: customers rated what they bought, and products with higher ratings ranked higher in search.
• Stack: Swift and Kotlin for the native apps the Noah team chose, an Angular and Laravel admin panel, Stripe for payments, and Google Maps for the producer map.

ShipMe: couriers and order statuses

ShipMe is our project for a parcel delivery service in Saudi Arabia, where customers posted shipments and carriers bid on them. An order was pending once placed, responded when it had received bids, and assigned when a bid was accepted. The courier stages that followed carry over to food delivery: awaiting pickup, ready for pickup, picked up, in transit, and delivered. The bidding does not, because food dispatch follows the kitchen's preparation time.

Corporate managers assigned deliveries to their drivers in a web dashboard, and customers tracked the parcel and chatted with the carrier in the app.

Our default tech stack for food delivery apps

For a new food delivery build, our default is one React Native codebase for the customer and courier apps, so iOS and Android ship together, and one backend that owns the order states.

• Customer and courier apps: React Native with Expo; react-native-maps for courier tracking.
• Kitchen screen: a Next.js or plain React web app, so a tablet in the kitchen needs only a browser.
• Admin panel: Laravel Backpack as our default, or Laravel Nova, for menus, orders, couriers, and reports.
• Backend: Laravel with PostgreSQL, and Redis for queues and caching during peaks.
• Live status: Laravel Reverb as the WebSocket server, so the customer and the kitchen see each change as it happens.
• Payments: a provider that handles tips and refunds, such as Stripe.
• Error tracking: Sentry, set up in your own account, so a crash in the courier app during dinner reaches the team before a courier calls.

How much does food delivery app development cost?

A full system costs from $30,000 for one brand. Every price in the table below is a starting price, not a range with a ceiling, and each one already includes design, project management, and testing.

Within each scope, the price grows with four things. Every role brings its own flows, so a courier app costs more to build than a connection to a delivery provider's API. An older POS with no API costs more to connect than one that has an API. Timing dispatch to preparation times is more work than sending every order to the nearest courier. A marketplace also needs the partner side: restaurant onboarding, a menu per restaurant, and payouts.

Design of every app, including the kitchen screen and the admin panel, is included in these prices, and so are project management and testing. The backend and the admin panel do not count as separate apps; each app that customers, couriers, or partner restaurants use does, and each one after the first adds from half the price of the first.

How to create a food delivery app

Work in this order: settle the type of service, the user flows, and the integrations before any design, and test with one real kitchen before the public release.

1. Choose the type and the first area. The business owner picks an own app, a marketplace, or a delivery-only kitchen, decides who delivers, and sets the launch area.
2. Map the user flows. The product team writes a user flow for each of the four roles: customer, kitchen, courier, and operator. If nothing is written down yet, you can order an analysis phase, paid separately and not required, that turns these flows into a written scope and a detailed estimate.
3. Get access to the integrations. The developers request API documentation and test accounts from the POS vendor, the payment provider, and the delivery provider if you use one.
4. Design the order around time. The designers build the checkout, the kitchen queue, and the tracking screens around preparation times and order states.
5. Build and show progress in sprints. The development team works in sprints that usually last one to three weeks, and each one ends with something you can open and check: screens ready to test, the latest build on the dev server, or updated mockups.
6. Test with one kitchen at a real peak. The restaurant team runs real lunch or dinner orders through the system before the public release, because problems that scripted tests miss show up under a real rush.
7. Release, then grow. The apps are published in the App Store and Google Play. When the launch area runs without manual help, the operations team adds restaurants and zones.

What to do next

You can start steps 1 and 3 yourself before you ask for quotes. For step 3, ask your POS vendor whether it has an API for menus and orders and a test account you can use now. Then make two decisions the steps do not cover.

1. Choose one business model for the launch. A commission if you run a marketplace, or a delivery fee or a subscription if the app sells your own food.
2. Budget from the cost table. Take the row for your scope and the matching support row; the build price already covers project management.

With those answers, an estimate describes your service and your kitchen, and the first version stays small enough to test at a real dinner rush.

First published 2024-03-20 by Dmitry Lauretsky, Former COO at Ronas IT. Rewritten by Alexander Storozhevsky.

Tell us who delivers, how many kitchens you run, and which POS you use, and we will come back with a rough estimate. We reply within 24 hours.

Get an estimate