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:
A seller requests a withdrawal
The request enters a pending queue — funds are not released automatically
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 UllahFull-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.
Leave a Reply