DEV Community

Faizullah
Faizullah

Posted on

Building a Multi-Vendor Marketplace From Scratch: Lessons From 30,000 Lines of React

#react #reactnative #refactorit

Building a Multi-Vendor Marketplace From Scratch: Lessons From 30,000 Lines of React

By Faiz Ullah — Full-Stack Developer & Founder of DG Technology

Most "build an e-commerce site" tutorials stop at a product list and a cart. They don't deal with the actual hard part: three different types of humans — customers, sellers, and admins — all needing their own secure space inside the same app, talking to each other in real time, without ever stepping on each other's data.

That's what I set out to build with Ecommerce, a multi-vendor marketplace that grew to over 30,000 lines of React. Here's what I learned engineering it.

The Real Challenge: Three Apps in One

A single-vendor store is one application. A multi-vendor marketplace is really three applications sharing a database:

  • Customers browse, buy, and chat with sellers
  • Sellers manage their own storefront, fulfill orders, and request payouts
  • Admins oversee everyone — approving sellers, resolving disputes, releasing payouts

The temptation is to bolt all three onto one App.js with a bunch of if (userType === 'admin') checks scattered everywhere. That gets unmanageable fast. Instead, I built three fully independent authentication systems, each with its own protected route guard:

<Route element={<ProtectedCustomerRoute />}>...</Route>
<Route element={<ProtectedSellerRoute />}>...</Route>
<Route element={<ProtectedAdminRoute />}>...</Route>
Enter fullscreen mode Exit fullscreen mode

Each guard checks its own session state independently. A seller session can never accidentally leak into the admin view, even if someone tries to manipulate the URL directly.

Real-Time Chat Without a Custom Server

I wanted buyers and sellers to message each other live — no page refresh, no polling. Rather than standing up a WebSocket server, I leaned on Firestore's real-time listeners, which turned out to be the right call for a project this size:

onSnapshot(query(messagesRef, orderBy('timestamp')), (snapshot) => {
  // UI updates instantly as new messages arrive
});
Enter fullscreen mode Exit fullscreen mode

This single pattern powers chat, unread-message counts, and live presence — all without me managing a single socket connection.

The Presence Problem

Showing whether a seller is "online" sounds trivial until you actually build it. A simple isOnline: true flag breaks the moment someone closes their laptop without logging out — they stay "online" forever.

The fix is a heartbeat pattern: the seller's client writes a lastSeen timestamp every few seconds while the tab is active, and stops the moment the tab closes or loses visibility:

document.addEventListener('visibilitychange', () => {
  if (document.hidden) stopHeartbeat();
  else startHeartbeat();
});
Enter fullscreen mode Exit fullscreen mode

Anyone viewing the seller's profile just checks: was the last heartbeat recent? No server-side cron job needed, no stale "online" ghosts.

Media at Scale: Don't Make Your Database Hold Images

Early on I made the rookie mistake of storing image data directly. That doesn't scale — Firestore documents have size limits, and serving large base64 blobs kills load times.

The fix was routing all uploads through Cloudinary, using unsigned upload presets so the API secret never has to live in client-side code:

formData.append('upload_preset', cloudinaryConfig.uploadPreset);
const res = await fetch(`https://api.cloudinary.com/v1_1/${cloudName}/upload`, {
  method: 'POST', body: formData
});
Enter fullscreen mode Exit fullscreen mode

Cloudinary then handles resizing, format conversion, and CDN delivery — the database only ever stores a URL.

The Payout Problem Nobody Talks About

Letting sellers earn money is the easy half. Letting them withdraw it safely is the half that actually matters. I built a dedicated WithdrawalRequestsManager so that:

  1. A seller requests a withdrawal
  2. The request enters a pending queue — funds are not released automatically
  3. An admin reviews and approves it manually before money moves

This manual checkpoint is deliberate. Automating payouts sounds efficient until the first fraud attempt — a human review step at the money boundary is the cheapest fraud prevention you can build.

What I'd Tell Someone Building Their First Marketplace

  • Separate your three user types from day one. Retrofitting role isolation onto a single auth system later is painful.
  • Use your database's real-time features before reaching for a custom server. Firestore's listeners replaced what would have been a whole separate real-time service.
  • Never store binary media where structured data lives. Offload it to dedicated media infrastructure immediately.
  • Put a human checkpoint wherever money actually leaves the system.

The Stack

Layer Technology
Frontend React, React Router
UI Material UI (MUI)
Database Firebase Firestore
Auth Firebase Authentication
Realtime DB Firebase Realtime Database (presence)
Media Cloudinary

Faiz Ullah
Full-Stack Developer · Founder of DG Technology
🌐 faizullah.pk · 💻 github.com/faizullahpk/multivendor-marketplace

If you're building something with multiple user roles and real-time data, I'd love to hear about it — follow along for more on shipping real-world full-stack systems.

Top comments (0)