B2B Commodity Trading Platform

The Problem

The client's B2B commodity trading platform was running on aging .NET/SQL Server infrastructure with no documentation and no migration path.

At stake:

• 3.7 million rows of transaction history, product data, and user accounts
• 125 GB of compliance files:certificates of analysis, licenses, trade confirmations
• 1,735 companies and 4,815 users on the platform
• 39,748 active product listings

The engagement had two mandates: preserve every byte of production data, then build a modern replacement from scratch.

Architecture

Four workstreams ran in parallel: data preservation, backend API, frontend application, and infrastructure.

What Was Built

Frontend

A large-surface trading application (50+ routed views across admin, broker, and trader roles) with 227 custom React components, real-time WebSocket state, and role-aware UI across every screen.

• Order Book:Live buy/sell depth with real-time updates. Orders are matched, locked, and negotiated through a multi-step proposal flow.
• Trade Book:Full trade history with counterparty details, filterable by date, product type, grade, and status.
• Matching Engine UI:Walks both counterparties through proposal, counteroffer, and confirmation. Lot-level locking prevents double-allocation.
• Product Listings:Card grid and hierarchical tree views. Clients submit products through a broker-mediated approval pipeline.
• Admin Panel:User/company management, data import, system settings, editable role-permission matrix with audit trail, and audit logs with bulk operations.
• Alias Mode:Brokers operate on behalf of any client without re-authentication.
• Multi-Domain Branding:Subdomain-based UI switching between admin and client interfaces.
• Demo Environment:Full API mocking layer with five demo accounts for stakeholder reviews.
• E2E Coverage:179 Playwright specs across 20+ suites: auth, admin, trading lifecycle, cross-role, regression, and smoke.

Backend

212 REST endpoints (287 operations) with OpenAPI 3.1.0 validation, deployed to EC2 via SSM with CI/CD health checks.

• Matching Engine:Core business logic pairing BUY and SELL orders with lot locking, counteroffers, partial fills, and multi-round negotiation.
• Deal & Confirmation Pipeline:Trade execution triggers PDF generation and automated email dispatch to both parties.
• Multi-tenant RBAC:Seven role tiers from GUEST to ADMIN, with permissions scoped per company and license type.
• Real-time Events:Socket.IO backed by PostgreSQL NOTIFY. Order book changes, trade confirmations, and admin actions push instantly to connected clients.
• Security Layer:JWT with rotating refresh tokens, rate limiting, session management via Redis, and brute-force prevention.

Data Migration

Data preservation was the first workstream. It started before any platform code was written, and it never fully stopped: the client periodically refreshes the platform against fresh source data.

• 3.7M rows extracted from SQL Server binary backups and transformed through a 12-stage ETL pipeline into PostgreSQL, respecting foreign key dependencies across 43 source tables.
• 111 GB of media (64,533 files) migrated to S3: COAs, lab results, licenses, trade confirmations, and product imagery.
• 29 transformation scripts (25 SQL phase/backfill scripts + 4 Python ETL scripts) handling schema mapping, data type conversion, and referential integrity validation across the full legacy-to-modern schema translation.
• Schema drift enforcement: a CI gate blocks any PR that alters a migration-target table unless the drift is explicitly acknowledged in a machine-readable allowlist, so the migration pipeline and the live schema can't silently diverge.

Infrastructure & Release Process

• CI/CD:GitHub Actions deploys the frontend to AWS Amplify and the backend to EC2 via SSM, with post-deploy health checks.
• Three-tier release gate:changes flow dev (internal sandbox) → qa (client-facing staging) → main (production), and production is never reached without the client's named stakeholders signing off against qa first.
• Daily Backups:Automated PostgreSQL exports to S3 with encryption and email notification. Sub-10-minute disaster recovery.
• Regression guards:the highest-risk flows (trade execution, listings display, the migration pipeline itself) are protected by dedicated Playwright/unit suites that must pass before any touching PR merges.

Technical Highlights

Legacy Platform Analysis

No documentation existed for the legacy system's business logic. I conducted a thorough platform analysis, mapping every workflow, data relationship, and edge case across order matching, trade settlement, permissions, and compliance. That analysis produced 13 feature specifications that became the blueprint for the rebuild.

Regulatory Compliance

Every product listing carries certificates of analysis, government license references, and compliance documentation. The RBAC system enforces visibility rules tied to license types. Different participant categories see different data based on their regulatory role. Lot-level traceability is maintained end-to-end.

Live Stakeholder Validation

The platform is past internal QA: it now runs on a recurring cadence of client-facing review. Client-reported issues are triaged, built, merged, and verified against the deployed staging environment the same day, with same-day cycles clearing a dozen-plus tickets at a time. Production releases require explicit sign-off from the client's named QA stakeholders against staging before promotion: not an automated gate, a human one.

AI-Assisted Development

Built across dozens of focused development sessions spanning many months, using specialized AI agent teams working in parallel: database architects, frontend developers, security auditors, and code reviewers coordinating simultaneously on different subsystems.

By the Numbers

The largest project in this portfolio by every measure: from legacy data preservation to a full trading platform now running in production for a regulated commodity market, under a live client validation cadence.