MAZAD PLATFORM.

The Problem Space

C2C marketplaces look simple on the surface — list, bid, pay, ship. They are not. A serious auction-and-marketplace platform requires ten distinct subsystems working in tight coordination: listings with lifecycle states, real-time bidding with anti-sniping, multi-mode pricing, escrow-held payments, fulfillment with deadlines and auto-closure, disputes with structured mediation, blind dual-ratings, multi-channel notifications, full-text search, and an admin back-office that controls all of it. Get any one wrong and the trust loop breaks. Build them naively and the platform either falls over under concurrency or quietly leaks money. We built MAZAD end-to-end to demonstrate what production-grade marketplace engineering looks like when none of those subsystems are cut corners on.

Functional Scope — Ten Interlocking Systems

1. Listings. Four pricing modes (auction, Buy Now, mixed Auction-and-Buy-Now, Make Offer with Buy Now), an 8-state lifecycle (Draft → Active → Flagged → Delisted → Ended Sold / Ended Unsold → Cancelled → Archived), per-listing stock and quantity tracking, multi-image upload with secure storage, listing snapshots captured at sale time so the order record never drifts when the live listing is edited, user reporting flow, and admin moderation.

2. Auction & Bidding. Manual bidding with platform-configurable bid increments, reserve price logic, anti-sniping time extension at auction end, complete bid history kept append-only (voided bids marked, never deleted), concurrent bid validation, and atomic bid acceptance transactions.

3. Make Offer. Up to 4-round counter chain (seller → buyer → seller → buyer), server-side minimum-offer threshold that is never returned to buyers, auto-rejection logic that is indistinguishable from explicit rejections on the client side, offer expiry handling, and listing-stays-active semantics until offer confirmation.

4. Payment & Escrow. Buyer-side transaction fee read live from platform config at checkout time and frozen on the order record at payment capture (never recalculated after), escrow hold on capture, deadline-triggered release on shipment confirmation, full atomic transaction wrapping for every money-touching operation, and a provider-pluggable architecture.

5. Order & Fulfillment. 9-state order lifecycle (Awaiting Payment → Paid → Shipped → Delivered → Closed), 48-hour seller shipment deadline with auto-cancellation on miss, shipment confirmation requires tracking number plus receipt photo, 14-day buyer confirmation window with auto-closure on inaction, and full state transition log kept append-only.

6. Disputes. Full state machine (Awaiting Seller Response → Seller Responded → Under Admin Review → In Mediation → Ruled → Closed), 48-hour seller response window, admin mediation thread with append-only message log, full and partial resolution outcomes, seller wallet freeze logic during disputes, and atomic ruling execution.

7. Ratings & Reviews. Blind dual-rating system enforced at the API layer — not just the UI — so party A's rating is never returned to party B until both have submitted or 30 days elapse. Aggregate profile scoring, seller response capability, and admin moderation.

8. Notifications. Three delivery channels (in-app, email, SMS/WhatsApp), full notification matrix mapping every business event to channel preferences, non-disableable system notifications, centralized dispatcher service so no business logic ever calls Resend or the SMS provider directly.

9. Search & Discovery. PostgreSQL full-text search abstracted behind a service interface (provider-swappable), multi-faceted filtering, sorting, hierarchical category browsing, watchlist, and homepage discovery surfaces.

10. Admin Back-Office. Separate auth guard from member sessions. Full audit log with IP-masking (last octet zeroed), user and listing management, dispute queue, payout controls, platform configuration management (fees, deadlines, windows — all live-editable without redeployment), and category management.

Technical Highlights

All financial operations are atomic database transactions. Bid acceptance, payment capture, fund release, refund, dispute ruling — each wrapped in a single transaction. Partial financial states are unacceptable; if any step fails, the entire operation rolls back. This is enforced at the database layer, not in application code where developers eventually forget.

Append-only audit on every consequential trail. Audit log, bid history, order status log, dispute log, notification log, rating records — all enforced as append-only at the database via Row Level Security policies. No UPDATE or DELETE permissions exist. This is what makes the platform forensically auditable months after the fact.

Three abstraction boundaries that protect future flexibility. Notification service (the only entry point for any dispatch), payout service with adapters (adding a new payout method is one new file implementing validate/initiatePayout/handleCallback), search service (provider-swappable without business logic changes). These boundaries were designed in from line one.

Zero hardcoded strings, zero hardcoded configuration. Every user-facing string is a typed key reference into one of three language files. Every configurable platform value — fees, deadlines, durations, window sizes — is read from a platform_config table at execution time. Admin changes take effect without redeployment.

Mobile-first trilingual UI with bidirectional layout. Arabic as primary language, displayed right-to-left; French and English as secondary, left-to-right. The HTML dir attribute switches based on active language. All Tailwind spacing uses logical properties (ms-, me-, ps-, pe-) so RTL flips automatically without UI-component rewrites.

Stack

Next.js 16 (App Router) + React 19 + TypeScript throughout. Tailwind CSS with logical properties for automatic RTL flipping. NextAuth v5 for authentication. Supabase for PostgreSQL database and file storage. Upstash Redis for rate limiting. Resend for transactional email. Framer Motion for UI transitions. Leaflet for location picking. Zod for runtime validation. 47 numbered SQL migrations owning the full schema design.

Status & What It Demonstrates

MAZAD is built to near-production engineering standards as an internal R&D project — currently paused pre-launch pending go-to-market resources, but architecturally complete. The patterns it demonstrates — atomic financial transactions, append-only auditability, hard service boundaries, abstracted provider adapters, server-validated state machines, mobile-first trilingual UX with RTL — transfer directly to any complex transactional platform a client might commission.

If you're building a platform where ten subsystems have to hold together without breaking trust, we should talk.