DAILY NEWS

Stay Ahead, Stay Informed – Every Day

Advertisement
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:

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.



Source link

Most Repos Look Fine. Until They Don’t.



You’ve been there.

You clone a repo. The README looks solid. There’s a Dockerfile. Maybe a docker-compose.yml. Everything appears set up.

Then you spend the next three hours chasing a missing config variable, an outdated base image, or a local development assumption that only makes sense if you’ve worked on the project for six months.

No one documents these things properly. They live in team memory, Slack threads, and that one engineer who “just knows.”

That’s the kind of engineering pain nobody tracks, and everybody absorbs.

The Hidden Tax on Every Team

Let’s be honest about what’s really happening.

Most engineering teams have gotten good at the visible stuff: code reviews, test coverage, deployment pipelines. But there’s a layer below all of that, repository readiness, that almost nobody validates with the same rigor.

Can a new developer clone this repo and actually run it?Does the Docker setup reflect how the project actually works today?Has the repo drifted from the workflow the team thinks it has?Is there tribal knowledge baked into the setup that stays invisible until something breaks?

These aren’t dramatic problems. That’s exactly why they survive so long.

The cost doesn’t show up in a postmortem. It shows up as:

onboarding that takes days instead of hours
“works on my machine” becoming a running joke
CI failures no one can explain right away
setup bugs being rediscovered by every new hire

None of that gets assigned a ticket. It just quietly eats time.

Why I Built dockgate

I got tired of watching this happen.

Not just to me, but to every developer stuck in the gap between “the repo exists” and “the repo actually works.” That gap has a real cost, and most of it is preventable.

So I built dockgate, a CLI that sits squarely in that gap and does one thing well:

It tells you whether a repository is actually ready to run, maintain, and trust.

Not whether the code is clean.Not whether the tests pass.Whether the operational layer, the Docker setup, project conventions, and environment assumptions, reflects reality.

What dockgate Actually Does

1. It detects what kind of project it’s dealing with

A Node.js repo, a Python repo, and a multi-service project should not be evaluated against identical expectations. dockgate starts with project detection so its checks stay relevant instead of noisy.

2. It uses a rules engine, not guesswork

This is where the tool stops being a script and starts becoming infrastructure.

Instead of scanning for random files and printing generic advice, dockgate uses a structured rule catalog. That makes evaluations more consistent, repeatable, and extensible.

You can use it for:

onboarding triage
repository audits
drift detection over time
validating Docker setup before handoff

Rules evolve as standards evolve. That’s where the leverage comes from.

3. It doesn’t just diagnose, it points forward

A lot of tools are good at listing what’s wrong. Fewer are designed to help you move toward a better state.

dockgate includes setup-oriented workflows so it can be part of actual remediation, not just diagnosis.

4. It fits how developers already work

It’s a CLI. It runs in the terminal. It works with hooks, audit scripts, and existing shell workflows.

That matters.

Good developer tools don’t ask people to change how they work just to get value.

What Makes It Different

There’s no shortage of linting tools, repo templates, and CI validators out there.

But dockgate focuses on something most of them skip: the setup layer. More specifically, the distance between “this repo exists” and “this repo is actually ready.”

That difference shows up in:

Docker support that works on paper but breaks in practice
README instructions that were accurate six months ago
environment assumptions only one team member still understands
local setups that quietly diverge from production

When the setup layer is unclear, the team pays for it every time someone new joins, every time a CI assumption breaks, and every time somebody has to reverse-engineer how the project is supposed to run.

dockgate makes that invisible layer visible.

On Shipping It Like a Real Tool

One thing I felt strongly about from the start was this:

there’s a huge graveyard of useful scripts that never became useful tools because they never crossed the gap between “works on my machine” and “someone else can install and trust this.”

I wanted dockgate to cross that gap deliberately.

That meant doing the less glamorous work too:

npm package support
PyPI wrapper support for Python environments
a changelog
a release checklist
a proper license
regression fixtures
a GitHub Actions publishing workflow

It also meant treating mixed-language teams as real users. dockgate is fundamentally an npm package, but developer teams rarely live in a single ecosystem. A PyPI wrapper lowers friction, and in developer tooling, accessibility often decides whether something gets tried at all.

The Lesson I Didn’t Expect

Building this reinforced something I keep coming back to:

some of the highest-value engineering work lives in problems people dismiss as small.

Setup friction looks small.Repository drift looks small.Docker inconsistency looks small.

Until it’s slowing down every sprint and nobody can fully explain why.

That’s the thing about infrastructure drag: it rarely announces itself. It accumulates. And it is always cheaper to catch early.

What’s Next

Right now, dockgate focuses on repository readiness and Docker validation. But the direction is bigger than that.

I can see it growing into:

stronger standards-driven validation
better drift detection over time
richer project profiles and baselines
more actionable remediation workflows

The foundation is rules-driven and extensible, which means it can grow with the teams that use it.

One Last Thought

A repository is not just a folder of code.

It’s an operational interface for every developer who touches it. When that interface is confusing, fragile, or full of hidden assumptions, the team pays for it whether they acknowledge it or not.

“It looks fine” is one of the most expensive things a repository can say.

dockgate is built to stop teams from taking that at face value.

Try dockgate on npm



Source link

MCP Server Design: 3 Principles We Learned in Production



Exposing a tool to an agent over MCP takes ten minutes. Building an MCP server that survives a model you don’t control, on a tight token budget with limited thinking time, is the part nobody warns you about.

We learned the difference shipping our own, consumed by third-party agents whose models we don’t pick. Three principles came out of it, each one we only fully believed after it broke in production:

TL;DR — three MCP server best practices from our trenches:

Fewer tools, narrower surface. Consolidate around the workflow, not the underlying API.

Consistent verbiage everywhere. Same name for the same concept across every input, output, and value on the server.

Validate against the protocol, not just your tests. The schema is the contract; everything else is a hint.

Background

We’ve been iterating on Trent’s MCP server; one public-facing surface for the product, consumed by third-party agents whose models we don’t control. Each iteration taught us something we’d half-believed going in but only fully internalized after it broke. These three principles have crystallized from that work, and they cut against the grain of how it feels to build a server when you’re moving fast. None of these are subtle in hindsight.

1. Fewer Tools, Narrower Surface

The instinct from regular software design, small composable units, single responsibility, doesn’t transfer cleanly to MCP. The consumer of the surface is an LLM with a finite attention budget, not another piece of software. The right size tool is the workflow, the agent is actually performing, not the smallest atomic operation in the underlying API.

Two reasons we’ve been aggressive about consolidation:

Overlap confuses tool selection. The trap usually isn’t tools that look identical; it’s tools that look distinct from the outside, with different names and different framings, but expose largely the same data with minor variations between them. The model has to decide which one is the “right” call for the workflow, and the decision is often arbitrary. On harder tasks it’s wrong in ways that are hard to debug. Consolidating those into a single tool, with the relevant slice exposed as a parameter, removes a degree of freedom the model didn’t need.

Every tool consumes context. If you’re exposing ~20 tools, the schema, name, description for each tool rides in the prompt every turn (once fetched). That’s a substantial chunk of context burned before the agent has done anything. Those tokens compound across a long loop and compete directly with the work the agent is actually trying to do.

Consolidating also tightens the loop for us as engineers. Fewer tools means a smaller surface to test, a smaller set of failure modes to observe, and a more direct path from a customer issue to the tool that caused it. The product gets simpler for the user, the workflow gets simpler for the model, and the codebase gets simpler for us. That alignment is rare; when you can find it, take it.

Concretely: we took our own MCP server from 17 tools down to 11, and the result was visibly better tool usage across the workflows that had been giving us trouble. The model spent fewer cycles on tool selection and the failure modes we were seeing on tighter constraints largely cleaned up. The current published version is trentai-mcp on PyPI.

The push to make this cut came from a pre-launch integration where Trent was exposed to end users through a third party’s chat interface. During testing we kept hitting cases where the chat couldn’t follow our instructions reliably, and tool overlap turned out to be a major contributor.

2. Consistency Across the Surface is a Correctness Property

MCP tool wording across the input schema, output schema, and the output values of every tool on a server needs to be consistent. If one tool calls a field user_id and another calls the same thing customer_id and a third returns accountId, the model has to reconcile that on every call. It mostly does, but reconciliation costs tokens, introduces ambiguity, and shows up as flaky tool calls in unpredictable conditions.

This matters more than it sounds because you don’t always control the model on the other side of the wire. When the MCP server is consumed by a third party, the agent could be running on a small model with a tight token budget and limited thinking time. Inconsistent naming that a frontier model would reason past, a smaller model just fails on. The same surface that looks fine in development collapses in a deployment you can’t see.

We ran into this during the same third-party pre-launch integration mentioned above. We exposed an update_tasks tool that let the chat write progress into a Trent security assessment, but the underlying API used control_id for the response field name and task_id for the input field name. The chat got confused between the two, the tool call failed repeatedly, and it couldn’t debug its way out. We didn’t catch this right away either; the 422s we kept seeing looked like a service-side bug, and we’d been debugging on the service end for a while before realizing the failure was upstream of the API, in the chat’s tool call. Making the naming consistent across input, output, and value cleared it up.

The frame I’ve started landing on is simple: the model on the other side of the wire is a variable you don’t get to pick. So design the surface for the lowest common denominator (consumer) that matters. Capable models reason past inconsistent naming; smaller ones fail on it. Consistency costs you one round of cleanup before you ship; inconsistency gets paid by every consumer, every call, forever.

3. Don’t Trust the Implementation Just Because it Works

This is the principle I’d most like to have learned sooner.

We built the MCP server with an agent. It worked. The tests the agent wrote alongside the implementation passed, our engineer-driven dogfooding ran cleanly, and the manual testing we did in the workflows we cared about all came back green. Beyond the tool selection and naming problems we covered earlier, we kept hitting a different class of failure that we couldn’t reproduce locally: the agent getting input shape wrong, invoking the tool in ways that didn’t match what we’d documented at all.

When we looked under the hood, the implementation hadn’t actually defined input and output schemas in the JSON properties the MCP protocol specifies. The agent that wrote the server had instead stuffed the entire contract, input shape, output shape, examples, into the description string of the tool, as a long comment-like blob. Frontier models read that and inferred the right structure. Smaller models, with less budget for inference, couldn’t. The fix is structural. MCP inputSchema and outputSchema are contracts, not hints. Stuffing them into the description string opts you out of every guarantee the protocol gives you.

Two lessons from that, both worth saying out loud:

Use the structure the protocol gives you. MCP defines inputSchema and outputSchema as discrete, structured fields for a reason: well-built clients use them to validate inputs, constrain agent behavior, and surface errors early. A description is a hint. A schema is a contract.

Agents get you to “working” faster than to “correct.” That gap is widest in unfamiliar territory, and a young protocol counts as unfamiliar territory, however many examples you’ve worked through. The agent picked a path that satisfied the tests it had written itself, evaluated by the same class of model that wrote them. It didn’t pick the path the protocol intended. We caught it because a stricter consumer broke; if we’d never had that consumer, we’d still be carrying the bug.

What we built with these principles

The server I’ve been describing — trentai-mcp — is how Trent shows up inside Claude Code. It runs the full Scan → Judge → Mitigate → Evaluate loop in your editor: surfacing threats relevant to your application’s architecture, prioritizing them against the real risk profile, generating a remediation plan that becomes tasks Claude Code can implement, and tracking how your security posture changes session over session.

MCP is still young, and the patterns for designing servers well are still being worked out across the industry. The three principles above are real world examples of what we’ve learned in production, and these principles are what I’d share with a new teammate, on day one when building a new server.

Originally published on the Trent AI blog — the full piece includes the worked example of the four consolidated tools.



Source link