HowWeBuildaFoodDeliveryMarketplace
Three apps from one Flutter codebase: a customer app, a restaurant dashboard, and a driver app. Real-time GPS over Socket.io, automated dispatch that scores the right driver instead of the nearest one, and a payment layer that splits every order between restaurant, driver, and platform.
This is how we build with our team when someone needs a real food delivery marketplace and not a WhatsApp group taped together with phone calls. The numbers above are how a build like this usually shapes up in the market. The rest of the page is the engineering underneath it. The decisions, the trade-offs, and the couple of things we got wrong the first time and had to fix.
The Problem We Keep Seeing
A regional delivery operation runs on WhatsApp groups and phone calls. Customers text orders to one number. A person reads them out to the restaurants. Drivers get dispatched in a group chat. It holds together at fifty orders a day. Push it to two hundred and the whole thing comes apart. Orders go missing. Delivery times creep past the hour. The team spends its day apologizing instead of growing.
So the brief is almost always the same shape. A three-sided marketplace where nobody is the human switchboard. Customers browse menus, order, and watch the delivery move on a map. Restaurants accept orders, flip items to sold out the moment they run out, and set their own prep times. Drivers get a route, their earnings in real time, and turn-by-turn directions. All three talking to each other automatically, with no group chat in the middle.
And the budget is rarely generous. A seed-stage company cannot bankroll three separate native apps with three separate teams. They want the customer app, the restaurant dashboard, the driver app, the backend, and an admin panel, all of it, in roughly fourteen weeks. They want Razorpay for the home market and Stripe wired up for whenever they cross a border. That tension, full marketplace on a tight clock and a tighter budget, is the constraint that shapes every call after it.
How We Build It
Three Flutter apps, one shared package layer. That is the move that makes the budget work. We pull the data models, the API clients, the auth, and the common widgets into a core package, and each app imports it and adds only its own screens. Roughly 70 percent of the code is shared. Fix a bug in the order model once and it is fixed in all three apps at the same time. Two Flutter engineers cover all three frontends while two backend engineers handle the Node.js microservices, the admin dashboard, and the real-time plumbing.
Here is the order flow. A customer places an order. The restaurant gets a push notification and a clock. They have ninety seconds to accept, and if they let it run out the order auto-routes to the next nearest place serving the same cuisine. Once it is accepted the dispatch engine picks a driver, the right one (more on that below), and hands them turn-by-turn directions. From the customer's side, the driver just starts moving on a live map.
The live map runs on Socket.io. The driver app streams its coordinates every few seconds, and we interpolate between points so the icon glides down the road instead of jumping. Geofencing does the quiet work here. Drop a 100-meter ring around each restaurant and the customer gets a "your driver has arrived" ping the second the driver crosses it, nobody pressing a button.
Flutter (3 apps, shared packages), Node.js (microservices), PostgreSQL, Redis, Socket.io, Google Maps API, Razorpay, Stripe, Firebase Cloud Messaging, AWS (EC2, S3, RDS)
The Decisions That Mattered
Shared packages over three independent codebases. We have said it already, but it is the decision everything else hangs off, so it earns the top spot. One core package, three thin apps on top. The payoff shows up every single sprint, because a change to a shared model lands everywhere at once and there is no third app quietly drifting out of sync. A build like this can come together weeks faster than three separate codebases would, and that head start is usually the difference between launching ahead of a competitor and chasing one.
Microservices over a monolith, for one concrete reason. The order service and the tracking service scale completely differently. Orders spike hard at lunch and dinner and go quiet in between. GPS tracking runs at a flat, constant hum all day. Split them apart and you can let the order service auto-scale through the rush without paying to over-provision the tracking service that never needed it. We design the system this way so the infrastructure bill follows the actual load instead of the worst-case peak.
The dispatch engine does not just grab the nearest driver. That sounds clever and behaves badly. Send the closest driver every time and the ones parked near the busy restaurant clusters get every order while everyone else sits idle. Worse, you send a driver who arrives in three minutes to a kitchen that needs twenty, so they stand around for seventeen. So we score three things instead: distance to the restaurant, what the driver is already carrying, and how long the food actually takes to cook. A driver two kilometers out with an empty bag can beat one five hundred meters away juggling two deliveries.
Payments run through two gateways behind one interface. Razorpay handles domestic UPI and cards. Stripe sits ready for international. The payment service hides both behind a single abstraction, so adding PayPal later, or switching a gateway out entirely, touches the backend and never the mobile apps. The money math, what the restaurant earns, what the driver earns, what the platform keeps, runs as a nightly batch in its own settlements service, well away from the live order path. (Keep the thing that moves money slow and auditable. Keep the thing customers stare at fast. They are different jobs.)
What Gets Built
Real-Time Order Tracking
The customer watches the order move through every stage. Confirmed, preparing, out for delivery, delivered. Once a driver picks it up, a live map takes over, and the icon glides along the route because we animate between GPS points instead of snapping to each one. The arrival estimate recalculates as it goes, off real distance and real traffic, so it is not lying to anyone the way a fixed countdown does.
Smart Dispatch Engine
This is the brain of the whole thing. Every available driver gets a score built from proximity, current load, restaurant prep time, and traffic. Highest score wins the order, and that is rarely the closest dot on the map. It also batches. Two orders leaving the same kitchen for the same neighborhood get handed to one driver, which trims a meaningful slice off the average delivery time without making either customer wait around for it.
Restaurant Management Dashboard
Restaurants run everything from a tablet-friendly Flutter app. New orders land with a sound and that ninety-second timer ticking. The menu editor flips an item to sold out in real time, so nobody orders the thing the kitchen ran out of an hour ago. Prep times adjust per order. A daily view shows the orders, the average ticket, and what the payout will be. They set their own hours, pause during a rush, and see their ratings. Small stuff, but it is the difference between a partner who trusts the platform and one who keeps a notebook beside the tablet.
Driver Earnings and Navigation
Turn-by-turn navigation lives inside the driver app, so nobody is flipping out to a separate maps app at a red light. Earnings show per delivery, with tips, daily totals, and a weekly summary. We usually layer in a light incentive too, finish a set number of runs in a shift and the bonus kicks in. Drivers care about two things above all else: clear directions and getting paid right. Build a system that designs for both and retention follows, because a driver who can see and trust their earnings is a driver who comes back tomorrow.
Payment Split and Settlements
Every order payment splits four ways the moment it lands: restaurant share, driver commission, platform fee, and tax. A nightly batch totals it all up and queues the bank transfers. The settlement service is built for the messy cases, not the happy path. A refund where the customer gets their money back but the restaurant still gets paid for food it already cooked. A partial cancellation. A tip adjusted after the fact. Reports drop out as CSV so the accounting side stays sane.
Admin Analytics Dashboard
The operations team gets the whole picture in one place. Live counts of active orders, drivers online, average delivery time, revenue per hour. Heat maps show where orders cluster by area and time, which is how you figure out where you are short on drivers before customers start feeling it. Restaurant rankings surface the partners with the worst cancellation rates or the slowest kitchens, so those conversations happen early. And it all rolls up into CSV exports for the weekly investor update.
What the Build Is Engineered to Do
These are the design targets we hold the system to, the engineering it takes to make a three-sided marketplace fast and dependable when the rushes hit. They describe the architecture and the goals we build toward, not any one client's numbers.
| Capability | Target | How |
|---|---|---|
| Code reuse | ~70% shared | One Flutter core package across all three apps |
| Live tracking | Few-second updates | Socket.io stream with interpolated map motion |
| Dispatch | Scored, not nearest | Distance, load, and prep time weighed together |
| Battery on shift | Survives a full day | Geofencing throttles GPS while a driver is parked |
| Scaling | Follows the rush | Order service auto-scales apart from tracking |
| Payments | Two gateways, one API | Razorpay and Stripe behind a single interface |
Build It, or Buy a Clone Script?
It's the first question almost every marketplace founder asks us. Build custom, or grab a clone script off the shelf? The gap between a $5K clone and a platform you can actually run a business on is wider than it looks from the outside. Here is the honest comparison.
| Approach | Cost | Timeline | Customization | Best For |
|---|---|---|---|---|
| Custom Marketplace Platform | $55K to $85K upfront | 3 to 4 months | Full control | Startups building a real marketplace with 3+ user types |
| UberEats Clone Scripts | $5K to $15K one-time | 1 to 2 weeks | Low (rigid codebase) | Testing an idea fast with minimal money down |
| Olo (restaurant-focused) | Custom pricing per order | 4 to 6 weeks | Moderate (restaurant-only) | Restaurant chains that want branded ordering |
| GloriaFood | Free (limited) / $29/mo premium | 1 to 3 days | Minimal | Single restaurants adding online ordering |
How much does a food delivery app like UberEats cost to build? The clone scripts promise the UberEats experience for ten grand. The reality is hardcoded logic, no real tracking, and a wall you hit the moment you want to change your commission structure or bolt on a loyalty program. We've rebuilt platforms that started life as clone scripts. Each rebuild cost more than building it properly from scratch would have. That is not a sales line. It is just what happens when you pour money into a foundation that was never meant to hold weight.
The three-sided pattern, customers and providers and the people connecting them, is not special to food. It is the same skeleton under ride-hailing, home services, and freelance marketplaces. So the real question is not the stack. It is whether the shape of the problem (live dispatch, payment splitting, ratings flowing three ways, surge logic) is something the team building it has actually shipped before, because that is what decides whether you hit the rushes ready or learn it live in production.
What We've Learned Building These
GPS will eat a phone alive if you let it. Our first pass on one of these polled location every second, and drivers started reporting dead phones halfway through a shift. So we backed off to a few-second interval and let geofencing do the rest. Park at a restaurant and the polling slows right down. Start moving and it picks back up. Tracking stayed accurate enough for the customer map, and the battery problem just went away.
The restaurant acceptance timer came later, and we wish it had come first. Without a timeout, some kitchens let an order sit for fifteen minutes while the customer assumed their food was already cooking. Adding the ninety-second clock with auto-reroute fixed it cleanly. The order either gets accepted fast or moves to a restaurant that will actually make it. Obvious in hindsight. Most of the good ones are.
Shared packages are a force multiplier that needs discipline, or they turn on you. Early on, somebody changed the shared order model and quietly broke the restaurant app, because the change looked safe in the one app they were testing. So we made a rule. Any change to a shared package runs the test suite across all three apps before it merges. It adds a few minutes to every pull request. It has saved us from shipping broken builds more than once.
And the dispatch engine always needs tuning against the real world. Our first version batched too eagerly. It would hold a ready order for minutes hoping a second one would appear heading the same way. Customers hated it, and fair enough, because their food was getting cold for the sake of someone else's. We tightened the batching window and added a distance threshold so the second order has to be genuinely close to the first. The clever optimization only counts if the food still shows up hot.
Frequently Asked Questions
How long does it take to build a food delivery app?
Plan on roughly 14 weeks for a full three-sided marketplace, meaning a customer app, a restaurant dashboard, and a driver app, plus the backend behind them. A simpler single-restaurant ordering app can ship in 6 to 8 weeks. The timeline scales with how many user roles you need and how much real-time work is involved, since live GPS and automated dispatch are the parts that take the longest to get right.
How much does a food delivery app cost to build?
In the market today a production-ready three-sided marketplace tends to run $55,000 to $85,000 for the first build, and a simpler single-restaurant app falls closer to $25,000 to $40,000. Hosting usually sits around $800 to $1,500 a month depending on order volume and how often the driver apps ping GPS, and payment gateways like Razorpay or Stripe take 2 to 3 percent per transaction. Those are market ranges to plan against, not a fixed quote from us.
Why use Flutter for a food delivery marketplace?
Because you are shipping three apps at once, and Flutter lets us build all three from one shared codebase. We design a core package that holds the data models, the API clients, the auth, and the common UI, so somewhere around 70 percent of the code is shared across the customer, restaurant, and driver apps. Going fully native would mean six codebases (three on iOS, three on Android) and a much larger team to keep them in sync.
How does real-time GPS tracking work in a delivery app?
The driver app streams its coordinates to the server every few seconds over Socket.io, and the server fans those updates out to the customer watching the order. Google Maps renders the driver position with smooth animation between points so the icon glides instead of teleporting. Battery is the catch. We use geofencing to slow the GPS down while a driver is parked at a restaurant, then speed it back up once they are moving, which is what keeps a phone alive across a full shift.
Can Geminate Solutions build a similar food delivery platform for our business?
Yes. The shared-package app structure, the real-time tracking layer, the dispatch engine, and the dual payment gateway are patterns we build with our team and reuse from one marketplace to the next. Geminate Solutions has shipped 50+ products. A platform like this usually takes 10 to 14 weeks. Start at geminatesolutions.com/get-started for a free project assessment.
Should you build a custom marketplace or use a clone script?
Use a clone script if you only need to test demand and you can live with hardcoded logic. Build custom the moment the marketplace is the actual product. Clone scripts tend to ship without real tracking and break as soon as you try to change the commission model or add a loyalty program. We have rebuilt platforms that started life as clone scripts, and the rebuild usually costs more than building it properly the first time would have.
What a Build Like This Costs in the Market
For planning, a full three-sided food delivery marketplace sits in the $55,000 to $85,000 range in the market right now. That covers the three Flutter apps (customer, restaurant, driver), the Node.js microservices, the real-time GPS layer, the dual payment integration, and the admin dashboard, plus the weeks of work to wire it all together. Running it tends to land around $800 to $1,500 a month, mostly hosting and Google Maps API calls that climb with order volume, with another few hundred for ongoing tuning and feature work. These are market ranges to budget against, not a quote from us. The real number depends on your order volume, how often you ping GPS, and how much you customize.
The more useful way to think about it is against the cost of not building it. A WhatsApp-and-phone-calls operation hits a ceiling, and the only way past that ceiling is hiring more people to be the human switchboard, month after month. A real platform takes that headcount off the table and lets the order count climb without the chaos climbing with it. Whether that trade works for your numbers is exactly the conversation we would rather have honestly up front than oversell.
Why Teams Bring This to Us
A marketplace like this wants Flutter, real-time systems, and payment-splitting experience in the same heads, all at once, and that mix is genuinely hard to pull together on a deadline. But more often the issue isn't the skill at all. The in-house team is already flat out on the core product, and pulling them onto a three-app build would freeze the roadmap for months. Building it with our team lets the company keep moving while the marketplace gets built in parallel, by people who have shipped this exact shape of thing before.
Speed to market is usually the real driver. Restaurant partnerships are a land grab, and every week you are not live is a week a competitor is signing the kitchens you wanted. We build with you as a product partner, not a code shop taking a spec over the wall. So when we say put a timeout on restaurant acceptance, or throttle the GPS with geofencing, or score the driver instead of grabbing the nearest one, that comes from watching these systems run in production, not from reading your ticket. We would rather tell you what tends to break than wait for it to break on you.
Related Resources
Thinking about building one?
The marketplace architecture, the dispatch engine, and the real-time tracking on this page are the same patterns we build with our team for your product. Tell us what you are trying to launch and we will tell you, honestly, what it takes.