Quotes for a food delivery app range from $3,000 to $150,000 for what sounds like the same product. The gap is almost never the screens. It is the operational depth behind them — dispatch, settlements, refunds, offline behaviour — and who is still maintaining it in month eighteen.
Here is what the three realistic routes actually cost.
Route 1: custom development
A credible build is five surfaces: customer app, vendor app, rider app, admin panel and backend API. Two competent mobile developers, one backend developer, a designer and a QA engineer for four to six months is the honest staffing level.
| Item | Low | High |
|---|---|---|
| Backend + admin panel | $8,000 | $25,000 |
| Customer app (iOS + Android) | $8,000 | $30,000 |
| Vendor app + panel | $5,000 | $15,000 |
| Rider app + tracking | $5,000 | $18,000 |
| Design | $2,000 | $10,000 |
| QA + launch | $2,000 | $8,000 |
| Total | $30,000 | $106,000 |
Add 15–20% a year for maintenance, OS updates and the bug list that accumulates after launch. Custom also means custom risk: if the developer leaves, the handover is whatever documentation they wrote.
Route 2: white-label SaaS
Entry pricing is usually $99–$499 a month, often plus per-order fees and a setup charge. It is genuinely cheap to start and usually the fastest to launch. The catch is structural: you are a tenant. The code is not yours, the roadmap is not yours, and price increases apply to you.
Run the maths over three years: $299/month is $10,764, and at the end of it you own nothing. For a business testing an idea, that can be rational. For a business that intends to exist, it is rent.
Route 3: productised software you install
Foodomaa is $299 once, installed on a server you rent for roughly $10–$20 a month. You get the five surfaces and the source code. The honest trade-offs: the design is ours, not bespoke, and features outside the product need either your developer or a paid change.
Three-year cost: about $660 including the server. That is not an argument that custom development is bad — it is an argument that most first launches do not need custom development.
The costs nobody quotes
- Payment gateway — 1.5–3.5% per transaction, plus chargeback fees.
- SMS / OTP — $0.01–$0.06 per message; OTP alone can be a real line item at volume.
- Maps — free tier covers a pilot, then usage-based pricing.
- Push notifications — free at low volume, paid above a few hundred thousand a month.
- App store accounts — $25 once for Google Play, $99/year for Apple.
- Rider acquisition — the one people forget. Bikes, bags, guarantees and churn.
- Support — someone has to answer "where is my order" at 9pm, and it should not be the founder forever.
What actually decides the budget
Not the app count. Three things: how much of the order lifecycle you customise, how many payment methods you support, and whether you need real dispatch optimisation. Everything else — menu, cart, tracking, reviews — is solved territory and should not be priced like a research project.
A useful rule: if your differentiator is not the software, do not spend your launch budget on the software. Spend it on supply density, which is the thing competitors cannot copy in a weekend.
A line-item cost table
Custom-build quotes are hard to compare because they bundle different scopes. Ask for a line-item breakdown using the same categories:
| Workstream | Typical share of a custom build | What to check |
|---|---|---|
| Discovery and UX | 5–10% | Order flows, rider states, admin roles |
| Customer app | 20–30% | Menu, cart, payments, tracking |
| Restaurant app/panel | 15–20% | Acceptance, prep time, menu control |
| Rider app | 10–15% | Assignment, navigation, proof, cash |
| Admin and settlements | 15–20% | Zones, commissions, payouts, reports |
| QA, deployment, stores | 10–15% | Device testing, review, handover |
A quote that is missing the rider app or the settlement engine is not a lower price; it is a smaller scope.
Custom vs licence vs SaaS
A custom build gives you exactly the flow you specify, but you pay for discovery, design, development, QA and maintenance. A source-code licence gives you a working baseline for a fraction of the cost, but you accept the product's model and customise around it. A hosted SaaS is the fastest and least owned option; it is best for validation, not for a business that expects to run for years on thin margins.
For a standard restaurant marketplace, the licence plus implementation is usually the rational first buy. For a genuinely novel operation, custom can be justified. The mistake is buying custom for a standard model and spending the launch budget on code instead of restaurants and riders.
Maintenance and hidden costs
- Security patches and dependency updates.
- App-store target-SDK releases and review delays.
- Payment gateway API changes and refund issues.
- Server monitoring, backups and incident response.
- Support staff during meal peaks.
- Refunds, chargebacks and failed-delivery costs.
Budget 10–20% of the initial build per year for maintenance. A custom build that is not maintained becomes a liability faster than a product licence because there is no vendor baseline.
How to reduce cost without breaking the product
- Launch one zone and one delivery model.
- Use a standard menu and standard payment methods.
- Skip custom dispatch until you have data that the default rules are wrong.
- Buy the three apps and admin instead of building each one.
- Spend the savings on restaurant supply, rider density and marketing.
A quote template you can send
Send this scope to every agency so the quotes are comparable:
- Customer app: menu, modifiers, cart, checkout, payments, order tracking, offers, reviews.
- Restaurant app/panel: order acceptance, prep time, menu and stock control, settlement view.
- Rider app: assignment, navigation, pickup/drop states, proof of delivery, cash collection.
- Admin: vendors, zones, commissions, payouts, refunds, reports, roles.
- Integrations: payment gateway, SMS/OTP, maps, push notifications, email.
- QA, deployment, app-store publishing, documentation and 30-day support.
Ask for the exclusions in writing. A quote that excludes the rider app, testing or store publishing is not comparable.
What changes the price most
Dispatch logic, payment methods, custom reports and integrations are the expensive parts. Screens and menus are solved territory. If your differentiator is not the software, do not pay for custom dispatch before you have data that the standard rules fail. Spend the budget on restaurant supply and rider density instead.
Payment and app-store costs
Add gateway setup and per-transaction fees, SMS/OTP, maps, push notifications, Google Play ($25 one-time) and Apple ($99/year). These are small individually and material at volume. A 2.5% payment fee on $25,000 monthly GMV is $625 a month, or $7,500 a year.
Build vs buy decision
| Question | Build | Buy licence |
|---|---|---|
| Standard restaurant marketplace | Overkill | Best fit |
| Novel routing or compliance | Justified | Constrained |
| Launch in under 8 weeks | No | Yes |
| Budget under $10,000 | No | Yes |
| Have a development team | Required | Recommended |
What a $5k, $15k and $50k quote actually buys
Three quotes can all say “food delivery app” and buy completely different products. The price usually tracks scope, team seniority and how much of the operation is already solved.
| Budget | What you can realistically expect | What is usually missing |
|---|---|---|
| ~$5,000 | One platform, template UI, basic customer and vendor flows, one payment gateway | Rider app, settlements, testing, store publishing, support |
| ~$15,000 | Three apps or a responsive web app, standard dispatch, two gateways, basic admin | Custom routing, advanced reports, multi-city, long warranty |
| ~$50,000+ | Custom UX, multi-city zones, complex pricing, integrations, QA and launch support | Everything still needs a maintenance budget |
A $5,000 quote is not automatically a scam. It may be a small team using a template and a narrow scope. The problem is when the buyer expects a $50,000 product for $5,000. Ask for the scope in writing, then compare line by line.
Change requests and scope creep
Most custom builds do not fail because the original estimate was wrong; they fail because the scope keeps growing without a change process. A new report, an extra payment method, a different rider rule or “just one more screen” each looks small. Together they add weeks.
Agree a change-request format before work starts: description, reason, impact on timeline, impact on cost and acceptance criteria. Approve or reject it in writing. A good agency will welcome this because it protects both sides. An agency that treats every change as free is either absorbing it into a higher price or heading for a dispute.
Protect the launch scope. Put nice-to-have features in a phase-two list and ship the core loop first: browse, order, pay, accept, dispatch, deliver, settle, refund. If phase one cannot do those eight things reliably, phase two does not matter.
Three-year total cost of ownership
Compare the three-year cost, not the build price. A simple model for a standard three-app platform:
| Line | Custom build | Source-code licence |
|---|---|---|
| Initial build / licence | $25,000 | $299 |
| Branding and implementation | Included | $2,000–$6,000 |
| Hosting and services (3 years) | $3,600 | $3,600 |
| Maintenance (3 years) | $18,000 | $6,000–$12,000 |
| Major changes | $5,000+ | $3,000+ |
| Approximate 3-year total | $51,600+ | $15,000–$22,000 |
The custom build can still be right when the operating model is the differentiator or when the licence cannot support a required integration. But the decision should be made with the three-year number, not the first invoice. The same logic applies to hosted SaaS: a low monthly fee can become the largest line at volume, while a licence can be expensive if nobody maintains it.
Payment, app-store and compliance costs
- Payment gateway: setup, per-transaction fee, chargeback fee and settlement delay.
- Google Play: one-time developer registration and a review process for each app.
- Apple Developer: annual fee, plus a Mac or cloud build service for iOS releases.
- Maps: free tier, then usage-based pricing for geocoding and directions.
- SMS/OTP: per message, with fraud and international-rate risk.
- Push: Firebase is free at launch, but usage and tooling can grow.
- Legal: terms, privacy, refund policy and local food-compliance review.
These are operating costs, not development costs, and they continue after the build. Put them in the same model as rider and marketing costs. A platform that costs $299 to license but $2,000 a month to operate is not a $299 business.
How to read an agency quote
Quotes are hard to compare because they use different words for the same work. Read the exclusions first, then the payment schedule, then the price.
| Signal | What it usually means |
|---|---|
| “All features included” with no list | No fixed scope; expect change requests |
| No rider app in the scope | The platform cannot complete delivery |
| No app-store publishing | You will need a developer or a Mac at launch |
| No QA or device testing line | You are the QA team |
| 100% payment up front | No leverage if delivery slips |
| No handover or documentation line | The agency remains a single point of failure |
| No maintenance quote | The build price is not the operating price |
A sane payment schedule ties money to milestones: discovery, clickable prototype, core build, integration, QA, launch and handover. Hold a meaningful final payment until the handover pack is complete. If the agency refuses any milestone structure, that is a risk signal, not a negotiation tactic.
Ask what happens after launch: who fixes a payment callback at 11 pm, who rebuilds the app for a new iOS version and who owns the repository. A cheap build with no maintenance path is expensive in month four.
The maintenance reserve
Set aside a monthly reserve from launch, even if nothing breaks. A realistic planning range is 1–2% of the original build cost per month for a custom platform, or a fixed care plan for a licensed product. The reserve covers framework and security patches, gateway changes, app-store releases and small fixes.
Do not fund maintenance from the next sale. A platform that only gets attention when a customer pays is a platform that degrades between sales. The reserve is part of the cost of owning software, not an optional extra.