A Tier-2-city food and grocery brand wanted to skip the Swiggy/Instamart commission and run their own multi-vendor app. Eight months later, the platform was live across two cities with 320 vendors, 850 daily orders, and 12,000 monthly active users.
The client runs a regional grocery brand with eight physical stores plus 90+ partner vendors (butchers, fish-mongers, fruit-and-veg shops, dairies). Customers were ordering on WhatsApp; reconciliation was a nightmare; and the founder did not want to hand 25% commission to a national aggregator. They needed their own app — but with the operational discipline of a Swiggy and the trust of a neighborhood store.
We scoped a four-app marketplace: customer, vendor, rider, and admin — sharing one Laravel API and a real-time event layer. The non-obvious decision was building the vendor app first; without vendors keeping inventory honest, no consumer app can survive its first viral week.
Address-first home screen (so customers see only stores that actually deliver to them), category browse, cart with multiple-vendor support, scheduled delivery slots, multiple payment methods (UPI, COD, wallet), real-time order tracking, ratings, re-order, refer-a-friend, and offer engine.
Vendor receives the order on their phone, taps Accept, picks the items, marks ready. Inline catalog management (add/edit products, mark out of stock, set timing), order history, payouts dashboard, and a self-service KYC + bank-detail flow at onboarding.
FCM push for new pickups, navigation, single-pickup multi-drop support (a rider can carry 3 small orders), proof-of-delivery photo + OTP, daily earnings, weekly payouts, support chat.
Live ops control: orders board, vendor onboarding queue, rider onboarding queue, dispute desk, pricing & commission rules, reports, push-notification builder, and an offer engine that can target by city, category, or customer cohort.
Laravel REST + queue workers, MySQL with read replicas, Redis for cart sessions, Firebase Realtime DB for order-state streaming and rider location pings. Razorpay for payments. Twilio for SMS, FCM for push. CI/CD via GitHub Actions to AWS.
We picked the stack for fit, performance under realistic load, and operational simplicity. Here is the breakdown:
Flutter for all three apps: we ship one design system, three apps, two stores. The customer + vendor + rider stack would have been 6 native projects otherwise. Build cost dropped ~40% vs three native iOS + three native Android codebases.
Laravel for the API: the team is fluent in it, the ecosystem (Eloquent, Horizon, Telescope, Sanctum) covers 90% of what you need. Performance under load was fine to ~200 RPS; we did the usual cache-and-queue work to handle peak-hour spikes.
Firebase only where it earned its place: realtime order state and live rider tracking. Everything else stayed on Postgres-shaped data in MySQL. This kept the Firebase bill predictable.
Inventory honesty.
A multi-vendor marketplace lives or dies on inventory accuracy. If a customer orders three items and the rider reaches the store and one is out of stock, that customer is gone — and probably tells two more.
We attacked this in three layers:
Cancellations from stock-outs went from 8% to 1.4% in three months.
We launched in a single neighborhood — five vendors, 200 hand-recruited customers, four weeks of bug-bashing under heavy ops involvement. The mistake we did not make: we resisted the pressure to expand earlier. The data from those four weeks reshaped the rider app twice and the vendor app three times.
City rollout was driven by a configuration-first architecture. Adding a city = creating a city record, defining delivery zones, setting per-category commissions, and onboarding vendors. A new city went live in six working days the third time round.
“We owned our customer relationship for the first time. The aggregator commissions we used to bleed are now in our P&L. The team got the vendor app right — that is the unsexy thing nobody else gets right.”
Co-Founder & CEO
Multi-Vendor Marketplace · Tier-2 India
Build the offer engine into v1, not v2. We launched without sophisticated targeting and the first three city marketing campaigns relied on flat 10% promos, which trained the wrong cohort. By v2 we shipped cohort + behaviour targeting; by then we had spent on customers we did not need to.
Whether you are replacing aggregator dependence or scaling a regional brand, we ship marketplace v1 in 4-5 months with the operational discipline you actually need. Quotes are scoped against builds like this.
Get a Free Consultation
