Forem: Surendra Kumar

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

Surendra Kumar — Tue, 28 Apr 2026 05:37:47 +0000

Hey everyone, Surendra Kumar here —Flutter/Firebase developer from Banda, India. I've been building production apps under Gfood Delivery Private Limited, and today I want to share the architecture behind my most ambitious project yet: Zesto, a multi-city food delivery platform built entirely with Flutter and Firebase.
Zesto isn't a tutorial project. It's a real, working platform — 4 Flutter apps, a complete Firebase backend, and architecture decisions modeled after how production platforms like Zomato actually work.
Want to try it before reading? Download the customer app APK and test it yourself:
Download Zesto Customer App https://github.com/ssurekumar01111-hue/zesto-demo/releases/download/v1.0-beta/app-release.apk
I'd love your feedback and improvement ideas after reading.

The 4-App Ecosystem
Zesto consists of four interconnected Flutter applications:

Customer App — Multi-city restaurant discovery, cart, Razorpay + wallet payments, live GPS tracking, reviews
Restaurant Partner App — Order management, menu CRUD, earnings dashboard, FCM order alerts
Driver App — Order accept/reject, live delivery tracking, earnings, payout requests
Flutter Web Admin Panel — 14 screens covering cities, zones, restaurants, drivers, orders, analytics, reviews, ads, config, and audit logs

The Core Architecture Decision: City + Zone Scoping
This is the most important architectural decision in Zesto — and the one that separates it from basic food delivery tutorials.
Every single Firestore document has two fields:
dart{
"city_id": "banda_up",
"zone_id": "banda_zone_1",
// ... rest of document
}
Every query filters by city_id first:
dartFirebaseFirestore.instance
.collection('restaurants')
.where('city_id', isEqualTo: currentCityId)
.where('is_active', isEqualTo: true)
.snapshots();
Why does this matter? Without city scoping, as you add cities your queries return restaurants from everywhere. Firestore has no built-in geographic filtering — you have to design it in from day one. Retrofitting this later would require rewriting every query and migrating every document.
Zones sit inside cities and control driver assignment. When an order is placed, the Cloud Function assigns it to available drivers in the same zone first, then expands to the full city if no zone drivers are available.

Firebase Custom Claims for RBAC
Zesto has 5 user roles: customer, restaurant_owner, driver, admin, super_admin. Managing this with Firestore documents alone creates security holes — a user could theoretically write to their own document and escalate their role.
The solution is Firebase custom claims set via Cloud Functions:
javascript// functions/src/admin/setUserRole.js
exports.setUserRole = functions.https.onCall(async (data, context) => {
if (!context.auth.token.super_admin) {

throw new functions.https.HttpsError('permission-denied', 'Not authorized');
}
await admin.auth().setCustomUserClaims(data.uid, {

role: data.role,
city_id: data.cityId,
});
});
On the Flutter side, the role is read from the ID token directly:
dartfinal token = await FirebaseAuth.instance.currentUser?.getIdTokenResult();
final role = token?.claims?['role'] as String?;
This means even if someone modifies their Firestore document, the custom claim on the token is what gates access. Firestore rules enforce this:
javascript// firestore.rules
match /orders/{orderId} {
allow read: if request.auth.token.role == 'admin'

|| request.auth.token.role == 'restaurant_owner'
|| request.auth.uid == resource.data.customer_id;
}

MobX for State Management
Zesto uses MobX across all 4 apps. Here's why I chose it over Riverpod or GetX for this project:
MobX's reactive observables map perfectly to Firestore streams. When a Firestore stream emits a new value, MobX automatically rebuilds only the widgets that consume that observable — no manual setState, no context.watch boilerplate.
dart// core/stores/order_store.dart
class OrderStore = OrderStore with $OrderStore;

abstract class _OrderStore with Store {
@observable
ObservableList activeOrders = ObservableList();

@observable
OrderStatus currentStatus = OrderStatus.placed;

@action
void updateOrderStatus(String orderId, OrderStatus status) {

final idx = activeOrders.indexWhere((o) => o.id == orderId);
if (idx != -1) {
activeOrders[idx] = activeOrders[idx].copyWith(status: status);
}
currentStatus = status;
}
}
The store subscribes to a Firestore stream once and updates observables. Every widget that reads activeOrders rebuilds automatically. Clean, testable, no rebuild storms.

Dual Payment Path: Razorpay + In-App Wallet
Zesto supports two payment methods and they interact with each other in interesting ways.
Razorpay handles card/UPI payments. The flow is standard — create an order via Cloud Functions, open Razorpay checkout, handle the webhook callback.
The wallet is more interesting. Each customer has a wallet_balance field on their user document. When they pay via wallet:
javascript// functions/src/payments/walletPayment.js
exports.processWalletPayment = functions.https.onCall(async (data, context) => {
const uid = context.auth.uid;

return admin.firestore().runTransaction(async (transaction) => {

const userRef = admin.firestore().collection('users').doc(uid);
const userDoc = await transaction.get(userRef);

const currentBalance = userDoc.data().wallet_balance;
if (currentBalance < data.amount) {
throw new functions.https.HttpsError('failed-precondition', 'Insufficient balance');
}

transaction.update(userRef, {
wallet_balance: admin.firestore.FieldValue.increment(-data.amount)
});

transaction.set(admin.firestore().collection('wallet_txns').doc(), {
uid,
amount: -data.amount,
type: 'debit',
order_id: data.orderId,
created_at: admin.firestore.FieldValue.serverTimestamp(),
});
});
});
The Firestore transaction ensures the balance check and deduction happen atomically — no race condition where two simultaneous orders drain the wallet below zero.

Cloud Functions: Domain-Split Architecture
Instead of one massive index.js, Zesto's Cloud Functions are split by domain:
functions/src/
├── orders/
│ ├── placeOrder.js # Create order, notify restaurant
│ ├── assignDriver.js # Zone-based driver assignment
│ └── onOrderDelivered.js # Earnings calculation, wallet credit
├── payments/
│ ├── razorpayWebhook.js # Payment confirmation
│ └── walletPayment.js # Wallet debit/credit
└── admin/

├── approveRestaurant.js
└── setUserRole.js
Each function is independently deployable. When I fix a bug in assignDriver.js, I deploy only that function — not the entire backend.

The Driver Assignment Problem
When an order is placed, the platform needs to assign a driver. Here's the simplified logic:
javascriptexports.assignDriver = functions.firestore
.document('orders/{orderId}')
.onCreate(async (snap, context) => {

const order = snap.data();

// 1. Find online drivers in the same zone
const driversSnap = await admin.firestore()
.collection('drivers')
.where('city_id', isEqualTo: order.city_id)
.where('zone_id', isEqualTo: order.zone_id)
.where('is_online', isEqualTo: true)
.where('current_order_id', isEqualTo: null)
.limit(5)
.get();

if (driversSnap.empty) {
// Expand to full city
// ... same query without zone_id filter
}

// 2. Send FCM notification to available drivers
// First driver to accept wins (handled by transaction in Driver app)
const tokens = driversSnap.docs.map(d => d.data().fcm_token);
await admin.messaging().sendMulticast({
tokens,
data: { type: 'NEW_ORDER', order_id: context.params.orderId }
});
});
On the driver side, accepting an order uses a Firestore transaction with three guards to prevent race conditions — only one driver can claim the order even if multiple tap Accept simultaneously.

What's Coming
Zesto is launching soon on Gumroad and Codester as commercial source code — complete, ready-to-customize. It includes all 4 Flutter apps, the complete Cloud Functions backend, Firestore security rules, and developer documentation.
Try the customer app right now:
https://github.com/ssurekumar01111-hue/zesto-demo/releases/download/v1.0-beta/app-release.apk
I'd genuinely love your feedback — what works well, what feels off, what you'd build differently. Drop a comment or reach me at Emails are not allowed.

Surendra Kumar — Flutter/Firebase developer, Banda, India
Portfolio: portfolio.gfood.in | GitHub: ssurekumar01111-hue

I Built a Complete On-Demand Home Services Platform in Flutter — 4 Apps, Live Tracking, Real Payments. Here's Everything Inside.

Surendra Kumar — Fri, 24 Apr 2026 07:20:03 +0000

Most "marketplace app" tutorials stop at a login screen.
I built the whole thing.
Customer app. Provider app. Handyman app. Full Flutter Web admin panel. Real Razorpay payments. Real-time Google Maps tracking. Firebase Cloud Functions handling all the backend logic. Push notifications. Earnings tracking. Payout system. Chat.
It took months of grinding as a self-taught developer from Banda, India.
You can have it today for $55.
👉 Get ServeNow Source Code on Gumroad

What Is ServeNow?
ServeNow is a production-ready, on-demand home services marketplace — think Urban Company or Thumbtack — built entirely with Flutter and Firebase.
It's not a demo. It's not a tutorial project. It's a fully integrated system with signed APKs, complete documentation, and demo credentials — ready to deploy or hand off to a client.
If you're a developer who wants to:

Launch your own home services business in your city
Sell a ready-made solution to a local client
Skip 4–6 months of building and go straight to customizing

...this is built for you.

The 4 Apps — What Each One Does
🧑‍💼 Customer App
The end-user experience. Customers can:

Browse services (beauty, cleaning, plumbing, electrical, and more)
Book appointments with real-time slot selection
Track their service provider live on Google Maps
Chat directly with their provider
Pay securely via Razorpay
Rate and review after the job

🏢 Provider App
For the businesses listing their services:

Accept and manage incoming bookings
Update service offerings and pricing
Track real-time earnings dashboard
Request payouts directly from the app

🔧 Handyman App
For the on-ground service professionals:

Broadcast job matching system — new jobs are pushed to nearby available handymen
First to accept gets the job (race conditions handled via Firestore transactions)
Onboarding and admin approval flow built in
Earnings and job history tracking

🖥️ Flutter Web Admin Panel
The control center for the marketplace owner:

Full user management (customers, providers, handymen)
Booking oversight and status management
Category and service configuration
Payout request processing
Analytics dashboard

Tech Stack — Why I Chose Each One
Flutter + Dart
Four apps. One codebase. That's the core advantage.
Flutter's native compilation keeps performance smooth across all four apps. Hot reload kept my development cycles fast. The widget library handled UI consistency without extra effort.
Firebase (My backend of choice for indie development)
Firestore is the heart of ServeNow's data layer. I went with denormalized data — embedding critical booking details directly in booking documents to minimize cross-collection reads. Subcollections handle nested data like chat messages.
Cloud Functions (JavaScript) handle everything that shouldn't happen on the client:

Razorpay webhook processing — payment callbacks update booking status server-side
FCM push notification triggers — booking updates, new job broadcasts, chat alerts
Earnings calculation and aggregation
New provider/handyman approval flows

Firebase Auth handles secure user management across all four apps.
Firebase Storage manages profile images, service photos, and media.
FCM (Firebase Cloud Messaging) powers real-time communication — from notifying handymen about new jobs to alerting customers when their pro is on the way.
Razorpay
Integrated as the primary payment gateway. Cloud Functions handle the success/failure webhook callbacks securely — no payment logic sits on the client.
Google Maps
Live handyman tracking, service area definition, job location visualization.
RxDart
Used for reactive state management — handling complex data streams cleanly, especially for real-time booking status updates across apps.

The Hardest Problems I Solved
Real-time synchronization across 4 apps
When a handyman accepts a job, the customer sees it instantly. The provider app reflects the status change simultaneously. This required careful Firestore listener management and Cloud Function triggers firing in the right sequence.
Job broadcasting without race conditions
When a new booking arrives, eligible handymen in the area all get notified at once. Only one can accept. I used Firestore transactions inside Cloud Functions to handle this atomically — first write wins, rest get rejected cleanly.
Secure payout flow
Earnings are tracked in real-time in Firestore. Providers and handymen request payouts through the app. The admin panel surfaces these requests for processing. All balance updates go through Cloud Functions to prevent client-side manipulation.
Building for production, not demos
The architecture was designed to scale — Firestore's horizontal scaling and serverless Cloud Functions mean you're not re-engineering the backend when you get real users.

What's Included
✅ Full source code for all 4 Flutter apps (Customer, Provider, Handyman, Admin Web)
✅ Firebase Cloud Functions (Node.js) — production-ready
✅ 16-page developer documentation (v2.0) — setup to deployment
✅ Signed APKs for immediate testing
✅ Demo credentials for all user roles
✅ Razorpay integration (test + live mode ready)
✅ Google Maps integration
✅ Complete Firebase security rules

Who This Is For

Flutter freelancers — sell this to a local business client, charge ₹50K–₹2L for customization
Entrepreneurs — launch a home services marketplace in your city without building from scratch
Developers — study a real production-grade multi-app Firebase architecture
Agencies — white-label and deploy for clients

Pricing
$55 one-time — no subscriptions, no royalties, full source code ownership.
Compare that to 4–6 months of development time at any reasonable hourly rate.
👉 Get ServeNow on Gumroad — $55
Also available on Codester.

About Me
I'm Surendra Kumar — a self-taught Flutter and Firebase developer from Banda, Uttar Pradesh. I build production-grade multi-app ecosystems and sell the source code for other developers and entrepreneurs to launch with.
This is real work, built by a real indie developer who ships.

GitHub: ssurekumar01111-hue
LinkedIn: surendra-kumar-58320145
Email: ssure.kumar01111@gmail.com

Questions about the code, architecture, or customization? Drop them in the comments — I reply to everything.
👉 Get ServeNow Source Code — $55