menu
I Built a Complete Zomato-Style Food Delivery Platform in Flutter — Here's What I Learned

I Built a Complete Zomato-Style Food Delivery Platform in Flutter — Here's What I Learned

Leader ●3 ●6 ●28
calendar_today • schedule1 min read

Just shipped Zesto — a full food delivery ecosystem with 4 Flutter
apps and a Firebase backend. Here's what the build taught me.

What's in the project

Customer App — OTP login, restaurant discovery, cart,
Razorpay payments, live driver tracking on Google Maps
Driver App — auto job assignment, step-by-step delivery
slider, background GPS foreground service
️ Restaurant App — real-time order dashboard, menu management
️ Admin Panel — Flutter Web, multi-city management

Backend: 20+Firebase Cloud Functions (Node.js 18)

3 Things That Bit Me Hard

  1. Never trust client-side prices
    My original placeOrder Cloud Function accepted grand_total from
    the app. Anyone could send grand_total: 1 and get free food.
    Fixed by recalculating everything server-side from Firestore menu
    prices — never touching the client value.
  2. Status string consistency across 4 apps
    Flutter enums use camelCase by default (arrivedAtRestaurant).
    Firestore stored snake_case (arrived_at_restaurant). Silent
    mismatches everywhere. Lesson: standardize from day one and use
    a safe parser that never throws on unknown values.
  3. MobX reactions fire on every change — not just the first one
    My HomeScreen reaction was pushing a new delivery screen every time
    activeJob updated — including status changes while the driver was
    already on the delivery screen. Three screens deep by the time the
    order was delivered. A single boolean guard fixed it.

Tech Stack
Flutter 3.11+ · Dart · Firebase · Razorpay
Google Maps · MobX · Node.js 18 · GeoFlutterFire

The source code is available
If you're building something similar or want a real production
Flutter/Firebase codebase to learn from:
https://morningstar47jb.gumroad.com/l/tnevss
Demo video: https://youtube.com/shorts/rL2M5O5Tk50
Happy to answer any architecture questions in the comments.

3 Comments

•

The client-side price vulnerability is the most classic mistake in e-commerce and it's surprisingly easy to ship it to production unnoticed. Good catch.

Curious about your Cloud Function architecture: are you recalculating the cart server-side synchronously during placeOrder, or do you have a separate price validation step before the payment intent is created? The timing matters a lot with Razorpay if you validate after the payment succeeds you're in a tricky refund flow, but if you validate before you have a race condition window where menu prices could change mid-checkout.

The MobX reaction bug is one I've seen cause real support tickets. The boolean guard works, but a cleaner long-term pattern is using reaction() with a fireImmediately: false and disposing it inside the delivery screen's lifecycle prevents the guard from becoming a hidden global state dependency.

How are you handling the background GPS foreground service on iOS? Android foreground services are straightforward, but iOS background location has strict entitlement requirements that Apple often rejects on first review.

2 votes
•

@[abarth23] Great questions — let me address each one directly.

On the price validation timing: validation happens synchronously
inside placeOrder before any payment is processed. The flow is:

  1. Customer initiates checkout
  2. App calls createRazorpayOrder CF → server calculates
    grand_total from Firestore menu prices → creates Razorpay
    order with that amount
  3. Razorpay payment happens client-side
  4. On success, app calls placeOrder CF with the
    razorpay_payment_id
  5. placeOrder recalculates grand_total again server-side
    and verifies it matches the Razorpay order amount

So validation happens twice — once before payment to set the
correct charge amount, and once after to confirm nothing changed.
The race condition window you mentioned (menu price changing
mid-checkout) is real but acceptable for this use case — if it
fires, the order fails cleanly with a specific error and no money
is moved.

On the MobX reaction pattern: you're right that fireImmediately:
false with disposal inside the delivery screen lifecycle is
cleaner. The boolean guard works but does create a hidden
dependency on HomeScreen state. I'll refactor that in v1.1 —
the delivery screen should own its own navigation lifecycle
completely.

On iOS background GPS: honestly this is the biggest known
limitation right now. The current foreground service
implementation is Android-only using flutter_foreground_task.
For iOS you need:

  • NSLocationAlwaysAndWhenInUseUsageDescription in Info.plist
  • Background Modes entitlement (location updates)
  • Significant location change API as fallback

Apple does scrutinize this heavily — apps without a clear
delivery use case get rejected. For a buyer launching a real
delivery business the entitlement approval is straightforward,
but it's not plug-and-play like Android. I've documented this
as a known limitation in the technical docs.

Appreciate the detailed review — these are exactly the edge
cases that matter in production.

1
•

@[MorningStar47] The double-validation flow is cleaner than I expected using the Razorpay order ID as the anchor between the two checks is the right call. Most implementations I've seen only validate once (either pre or post) and hope for the best.

Good to hear on the MobX refactor. The delivery screen owning its navigation lifecycle is the correct mental model it also makes it much easier to test in isolation.

On iOS: the honest documentation is more valuable than a hacky workaround. Buyers with a real delivery business will have the entitlement approved in days. The significant-location-change API is worth implementing as a fallback though it survives app suspension without the entitlement and is accurate enough for most delivery radius use cases.

Good luck with v1.1.

2
🔥 Join developers growing publicly
Share your knowledge, build in public, and grow your developer presence with a global community.
Join CoderLegion

More Posts

How I Built a React Portfolio in 7 Days That Landed ₹1.2L in Freelance Work

Dharanidharan - Feb 9

Building a Zomato-Like Multi-City Food Delivery App with Flutter & Firebase

MorningStar47 - Apr 28

How I Built a Complete On-Demand Home Services App (ServeNow) with Flutter & Firebase

MorningStar47 - Apr 27

Sovereign Intelligence: The Complete 25,000 Word Blueprint (Download)

Pocket Portfolio - Apr 1

Breaking the AI Data Bottleneck: How Hammerspace's AI Data Platform Eliminates Migration Nightmares

Tom Smithverified - Mar 16
chevron_left
Surendra Kumar
2.6k Points • 37 Badges
India • portfolio.gfood.in
10Posts
19Comments
4Connections
Flutter and Firebase developer from Banda, India. I spend my time building
real, production-grade m... Show more

More From MorningStar47

What If Your Repository Could Explain Itself?

Built an Autonomous DFIR Agent SIFT-AEGIS — Here's What I Learned

🏗️ CasePilot — India's AI Legal Case Worker

Related Jobs

View all jobs →

Commenters (This Week)

6 comments
3 comments
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!