\n<\/p>\n
By Faiz Ullah \u2014 Full-Stack Developer & Founder of DG Technology<\/p>\n
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 \u2014 customers, sellers, and admins \u2014 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.<\/p>\n
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.<\/p>\n
The Real Challenge: Three Apps in One<\/p>\n
A single-vendor store is one application. A multi-vendor marketplace is really three applications sharing a database:<\/p>\n
Customers browse, buy, and chat with sellers<\/p>\n
Sellers manage their own storefront, fulfill orders, and request payouts<\/p>\n
Admins oversee everyone \u2014 approving sellers, resolving disputes, releasing payouts<\/p>\n
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:<\/p>\n
Route element={ProtectedCustomerRoute \/>}>…Route>
\nRoute element={ProtectedSellerRoute \/>}>…Route>
\nRoute element={ProtectedAdminRoute \/>}>…Route><\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
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.<\/p>\n
Real-Time Chat Without a Custom Server<\/p>\n
I wanted buyers and sellers to message each other live \u2014 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:<\/p>\n
onSnapshot(query(messagesRef, orderBy(‘timestamp’)), (snapshot) => {
\n \/\/ UI updates instantly as new messages arrive
\n});<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
This single pattern powers chat, unread-message counts, and live presence \u2014 all without me managing a single socket connection.<\/p>\n
The Presence Problem<\/p>\n
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 \u2014 they stay “online” forever.<\/p>\n
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:<\/p>\n
document.addEventListener(‘visibilitychange’, () => {
\n if (document.hidden) stopHeartbeat();
\n else startHeartbeat();
\n});<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Anyone viewing the seller’s profile just checks: was the last heartbeat recent? No server-side cron job needed, no stale “online” ghosts.<\/p>\n
Media at Scale: Don’t Make Your Database Hold Images<\/p>\n
Early on I made the rookie mistake of storing image data directly. That doesn’t scale \u2014 Firestore documents have size limits, and serving large base64 blobs kills load times.<\/p>\n
The fix was routing all uploads through Cloudinary, using unsigned upload presets so the API secret never has to live in client-side code:<\/p>\n
formData.append(‘upload_preset’, cloudinaryConfig.uploadPreset);
\nconst res = await fetch(`https:\/\/api.cloudinary.com\/v1_1\/${cloudName}\/upload`, {
\n method: ‘POST’, body: formData
\n});<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
Cloudinary then handles resizing, format conversion, and CDN delivery \u2014 the database only ever stores a URL.<\/p>\n
The Payout Problem Nobody Talks About<\/p>\n
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:<\/p>\n
A seller requests a withdrawal
\nThe request enters a pending queue \u2014 funds are not released automatically
\nAn admin reviews and approves it manually before money moves<\/p>\n
This manual checkpoint is deliberate. Automating payouts sounds efficient until the first fraud attempt \u2014 a human review step at the money boundary is the cheapest fraud prevention you can build.<\/p>\n
What I’d Tell Someone Building Their First Marketplace<\/p>\n
Separate your three user types from day one. Retrofitting role isolation onto a single auth system later is painful.<\/p>\n
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.<\/p>\n
Never store binary media where structured data lives. Offload it to dedicated media infrastructure immediately.
\nPut a human checkpoint wherever money actually leaves the system.<\/p>\n
The Stack<\/p>\n
Layer
\nTechnology<\/p>\n
Frontend
\nReact, React Router<\/p>\n
UI
\nMaterial UI (MUI)<\/p>\n
Database
\nFirebase Firestore<\/p>\n
Auth
\nFirebase Authentication<\/p>\n
Realtime DB
\nFirebase Realtime Database (presence)<\/p>\n
Media
\nCloudinary<\/p>\n
Faiz UllahFull-Stack Developer \u00b7 Founder of DG Technology\ud83c\udf10 faizullah.pk \u00b7 \ud83d\udcbb github.com\/faizullahpk\/multivendor-marketplace<\/p>\n
If you’re building something with multiple user roles and real-time data, I’d love to hear about it \u2014 follow along for more on shipping real-world full-stack systems.<\/p>\n