BrokerLink

BrokerLink is an end-to-end full-stack platform that connects customers who need brokerage services with brokers who can deliver them. The system is built around separate, role-scoped workspaces: each party signs in to a dashboard tailored to their responsibilities, while administrators retain visibility and control across the entire marketplace.

At its core, BrokerLink supports discovery, structured deal flow, real-time collaboration, and payments so that work can be scoped, tracked, paid for, and reviewed without leaving the product. File sharing, progress checkpoints, and notifications tie the experience together so both sides always know where a gig stands.

Matching with the right broker is rarely a single search result. Clients need trust signals (ratings, geography, category fit, budget), and brokers need clear deal records instead of scattered chats and invoices. Payments are especially sensitive: money should move only when milestones and platform rules are respected.

BrokerLink addresses this by combining searchable listings with filters, a defined deal lifecycle from creation through completion, in-product chat with guardrails, Stripe-backed payments, and an admin layer that can verify accounts and enforce policy before anyone touches sensitive features. Email keeps everyone informed when state changes, so verification, approvals, and payouts never feel like a black box.

Discovery and matching

• Rich filters so customers can find brokers by category, ratings, city, and price range, reducing noise and surfacing relevant profiles.
• Deal creation with space to capture scope and expectations before work begins.
• Progress tracking so both sides see how a gig advances from kickoff through delivery.

Collaboration and money

• Real-time chat alongside deals, with file sharing for briefs, contracts, or deliverables.
• Stripe-based payment flow integrated into the product so funds align with platform rules and deal state.
• Reviews after completion to close the feedback loop for future clients.

Three dashboards, one platform

• Customer, broker, and admin experiences are isolated by role: each tenant of the product sees the tools and data appropriate to their account, while admins can moderate users, approve access, and oversee activity network-wide.
• Profile and settings for self-service updates, plus data export where users need their own records.

Email notifications (custom SMTP)

Automated messages cover the full lifecycle: account verification, admin approval decisions, payment updates, gig creation, work completion, and review requests, all delivered through a dedicated SMTP integration so delivery stays under our control.

BrokerLink is implemented as a full-stack JavaScript web application: a React single-page client for fast, interactive dashboards and flows, and a Node.js service layer with Express-style routing for REST APIs, background-friendly tasks, and integration glue.

MongoDB (with Mongoose) stores users, deals, messages, and audit-friendly records in a document model that fits evolving marketplace fields. Socket.IO powers real-time chat and presence-style updates without polling the server to death.

Stripe handles card payments and webhooks so the database remains aligned with what Stripe confirms. JWT authentication protects APIs across all three dashboard types, and OTP email verification plus admin approval gates sit in front of feature access. Outbound mail runs through a custom SMTP service for the notification matrix above.

Architecturally, the emphasis is tenant-style separation: brokers, customers, and admins each operate inside scoped permissions and routes, while shared infrastructure (auth, payments, messaging) stays consistent and auditable.

Marketplace products mix social surfaces (chat) with regulated flows (money and identity). The hardest work was drawing a hard line: chat must not become an end-run around the platform, so blocking phone numbers, email addresses, and social links in messages required careful validation without frustrating legitimate technical discussion.

Admin approval before feature access added another state machine on top of signup: users could be verified by email yet still pending until staff reviewed them. That pattern had to stay clear in the UI and in every permission check.

On the payments side, Stripe webhooks and retries meant designing idempotent handlers so duplicate events never double-apply state. SMTP deliverability and template consistency for many notification types was another area where small misconfigurations would surface as support noise.

I enforced server-side rules for restricted chat content (with clear client hints so users understand why a message was rejected), and I treated JWT claims and role checks as mandatory on every sensitive route, not just the login screen.

The approval workflow is modeled explicitly: states like pending, approved, and rejected drive both API authorization and email triggers, so admins and users always receive the same story the database tells.

For Stripe, webhook signatures are verified, handlers are written to tolerate at-least-once delivery, and payment records update only from confirmed events. Socket rooms are scoped per deal or thread so messages do not leak across tenants.

Notification templates were grouped by event type (verification, approval, payment, gig, completion, review) so adding a new email later is a small, predictable change rather than a copy-paste sprawl across the codebase.

BrokerLink is the kind of project that proves full-stack work is not only CRUD screens: it is filters and trust, chat with policy, money with webhooks, email as a product surface, and admin power that keeps a multi-party system fair.

Going forward, the same principles guide how I build marketplaces: separate tenants by role, centralize policy on the server, and keep Stripe state and SMTP notifications in lockstep with what users see in the UI so discovery, deals, chat, and payouts stay coherent from end to end.