DEV Community: Surendra Kumar

I built a free AI writing SaaS with Flutter Web + Gemini — would love feedback from this community

Surendra Kumar — Sun, 17 May 2026 08:17:55 +0000

Hey Dev.to Community

I've been a Flutter/Firebase developer for the past
couple of years, and I recently shipped something I'm genuinely
proud of — ScribeAI, a free AI-powered writing platform.

https://scribeai-f7645.web.app

Here's what it does — 8 tools in one platform:

ATS Resume Scorer — paste your resume + job description,
get an instant compatibility score, missing keywords, and
improvement suggestions

✉️ Cover Letter Generator — tailored cover letters matched
to any job description

Document Summarizer — turn long contracts and reports into
clean structured summaries

Blog & SEO Writer — full SEO-optimized blog posts from
just a topic and keywords

✏️ Grammar & Tone Fixer — fix errors and adjust tone
(professional, casual, formal)

Paraphrasing Tool — rewrite text in multiple styles
and variations

LinkedIn Bio Writer — optimized About section that
attracts recruiters

Interview Q&A Generator — role-specific questions and
model answers

️ Tech stack for those curious:

Flutter Web (single codebase, runs in any browser)
Google Gemini AI API for all 8 tools
Firebase Auth + Firestore for backend
BLoC state management
Razorpay for payments
Deployed on Firebase Hosting
Monetization: Free tier (3 uses/day) → Credits (₹99 = 20)
→ Pro (₹199/month unlimited)

Other features: PDF download, copy to clipboard, share
results as public link, usage history, (signup needed to try)

This started as a side project to prove that a Indie-developer can build and ship a real SaaS product without
a team or funding.

I'd genuinely love feedback from this community on:

Is the UI/UX intuitive? Anything confusing?
Which tool did you find most useful?
What feature would make you actually use this regularly?
Any bugs you spotted?
Would you pay for the Pro plan? If not, why?
Be as brutal as you want — I can handle it and I'll
actually fix things based on your feedback

Thanks for checking it out!

How I Built a Complete Food Delivery Platform with Flutter and Firebase

Surendra Kumar — Sun, 10 May 2026 10:30:28 +0000

After months of building, I just released Zesto — a production-ready,
multi-city food delivery platform inspired by Zomato and Swiggy.
It consists of 4 Flutter apps backed by a Firebase backend with 23
Cloud Functions. In this article I'll walk through the key architecture
decisions I made along the way.

What I Built

Customer App — OTP login, restaurant discovery, cart, Razorpay payments, live driver tracking
Driver App — automatic job assignment, step-by-step delivery slider, background GPS
Restaurant App — live order dashboard, menu management, earnings
Admin Panel — Flutter Web, multi-city, restaurant and driver management

Demo: https://youtube.com/shorts/rL2M5O5Tk50

Architecture Overview
All 4 apps share a single Firebase project. Each app is independent
with its own package name and Firebase registration, but they all
read and write to the same Firestore collections.
Customer App ─────┐
Driver App ─────┤──── Firebase (Firestore + Auth + FCM + Functions)
Restaurant App ────┤
Admin Panel ─────┘
This approach kept things simple — no separate backends, no API
servers to manage. Just Firestore listeners and Cloud Functions.

State Management: MobX
I chose MobX over BLoC or Riverpod for one reason — the reaction
system. When the driver's order status changes in Firestore, I need
the UI to react at multiple levels simultaneously:

The map needs to update polylines
The slider needs to show the next step
The navigation stack needs to know whether to push a new screen

MobX reactions handle this cleanly:
dart_navigationReaction = reaction(
(_) => _driverStore.activeJob,
(order) {
if (order != null && !_isOnActiveDelivery && mounted) {
_isOnActiveDelivery = true;
Navigator.push(context, _deliveryRoute());
}
},
);
One thing I learned the hard way — reactions fire on every observable
change, not just null → non-null transitions. This caused the driver
app to push a new ActiveDeliveryScreen on every status update, stacking
screens on top of each other. The fix was a simple _isOnActiveDelivery
guard flag.

Order Status Flow
The biggest consistency challenge was keeping order statuses in sync
across 4 apps and 23 Cloud Functions. Early in development I had
camelCase statuses in Flutter (arrivedAtRestaurant) and snake_case
in Firestore (arrived_at_restaurant). This caused Firestore queries
to silently return empty results.
The fix was standardizing everything to snake_case and adding a safe
parser that never throws:
dartenum OrderStatus {
placed, confirmed, preparing, ready, accepted,
arrived_at_restaurant, picked_up, on_the_way,
arrived_at_customer, delivered, cancelled, refunded;

static OrderStatus fromString(String? value) {
return OrderStatus.values.firstWhere(
(e) => e.name == value,
orElse: () => OrderStatus.placed,
);
}
}
The full status progression looks like this:
placed → confirmed → preparing → ready → accepted
→ arrived_at_restaurant → picked_up → on_the_way
→ arrived_at_customer → delivered

Driver Assignment Algorithm
When a restaurant marks an order ready, the app calls the assignDriver
Cloud Function. Here's how it finds the nearest available driver:

Query zone_drivers/{cityId}/active/ — drivers who are online
Filter out drivers with updated_at older than 10 minutes (stale)
Calculate distance from each driver to the restaurant using
Haversine formula on GeoPoint coordinates
Assign the nearest driver
Delete the driver from the active pool (prevents double assignment)
Return success: false if no drivers are available

The trickiest bug here was a race condition — the driver app was calling
goOnline() before init() had finished reading the driver's real
cityId from Firestore. So the driver registered under a hardcoded
default city and was invisible to the assignment function.
The fix was a simple initialization guard:
dart@action
Future goOnline(String driverUid) async {
if (!_isInitialized) {
int retries = 0;
while (!_isInitialized && retries < 20) {
await Future.delayed(const Duration(milliseconds: 250));
retries++;
}
}
// now safe to use real cityId
}

Security: Why Client-Side Validation Is Not Enough
The most important backend fix was server-side price validation.
The original placeOrder function trusted the grand_total sent
by the client — meaning anyone could intercept the API call and
order ₹1000 worth of food for ₹1.
The fix was recalculating everything server-side:
js// Never trust client prices
for (const item of items) {
const menuItemSnap = await db
.collection('restaurants').doc(restaurant_id)
.collection('categories').doc(item.category_id)
.collection('items').doc(item.item_id)
.get();

const menuItem = menuItemSnap.data();
calculatedSubtotal += menuItem.price * item.quantity;
}
// Use calculatedSubtotal — never data.grand_total
I also locked down Firestore rules to prevent drivers from updating
their own wallet_balance and customers from setting
payment_status: paid without a real transaction.

The Toughest Bug
The driver delivery screen freezing after accepting an order took the
longest to debug. The symptoms:

Driver accepts order ✅
Screen appears frozen on "Processing..." ❌
Only fixed by clearing the app from memory and reopening

The root cause was actually three separate bugs compounding:

_updatePolylines() — an async method calling setState — was
being called directly inside an Observer build method. Flutter
suppresses secondary rebuilds to prevent infinite loops, causing
the UI to freeze.
The accepted status had no case in the delivery screen's switch
statement, so it defaulted to "Processing..."
The NewOrderOverlay dialog was never popped after acceptance,
leaving an invisible backdrop blocking all touches.

Each fix was simple in isolation — moving polylines to a MobX
reaction, adding the accepted case, and calling
Navigator.pop() on acceptance. But finding all three together
took a full investigation pass.

What I Would Do Differently
Shared package for models — each app has its own copy of
OrderModel and OrderStatus. A shared packages/core library
would have prevented the status mismatch bugs entirely.
Webhook-based payment confirmation — currently Razorpay payment
success triggers order creation from the client. If the app crashes
between payment and order creation, the customer loses money with no
order. A proper webhook reconciliation flow would be more robust.
iOS from day one — the driver app's foreground service needs
separate configuration for iOS. Building Android-first and adding
iOS later meant reworking the background location architecture.

The Result
A fully working food delivery platform that I've listed as source
code for other developers to use as a starting point.
🛒 Source code: https://morningstar47jb.gumroad.com/l/tnevss
Includes full SETUP.md, demo seeder, AppConfig for rebranding,
and all 23 Cloud Functions.
Happy to answer any questions about the architecture in the comments.

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