$500,000 donated. 2,000+ products listed. 350+ active sellers across Mexico. Those are not vanity metrics -- they are the result of deliberate architecture decisions our team made when building Platia, Mexico's leading B2B circular marketplace. This post breaks down the technical choices, tradeoffs, and lessons learned from building a platform that turns surplus inventory into charitable donations across four verticals: home goods, events, hotels, and restaurants.

If you are a CTO or VP of Engineering evaluating marketplace architecture for a B2B platform, this is the deep dive we wish we had before starting.

The Problem: B2B Circular Commerce in Mexico

B2B surplus inventory is a massive, underserved market. Hotels have unused furniture after renovations. Event planners have left over decor after large productions. Restaurants have excess equipment when they downsize or close. Traditionally, this surplus goes to landfills or gets picked up by informal middlemen at a fraction of its value.

The circular economy angle adds complexity. Platia does not just connect buyers and sellers -- it tracks the charitable impact of every transaction. When a seller donates surplus inventory through the platform, the system records the donation value and routes it to verified nonprofit organizations. This is not a bolt-on feature. It is core to the product.

Three problems made this non-trivial:

Trust gap in B2B transactions. Business buyers do not browse like consumers. They need bulk pricing, volume verification, and assurance that surplus goods meet quality standards.
Manual processes everywhere. Existing surplus inventory was managed through WhatsApp groups, phone calls, and spreadsheets. There was no centralized discovery layer.
Impact tracking requires data infrastructure. To credibly report $500K+ in donations, every transaction needed audit trails, receipt generation, and real-time dashboard aggregation across four distinct verticals.

Our team at 4M Labs was brought in to architect and build the platform from scratch. Here is how we approached it.

Architecture Decisions and Tradeoffs

Marketplace UX: B2B Is Not B2C

The first architecture decision was rejecting B2B2C marketplace patterns. Most marketplace frameworks (Medusa, Sharetribe, custom Shopify multi-vendor) optimize for consumer browsing behavior: browse, filter, add to cart, checkout. Platia needed a fundamentally different flow.

Business buyers on Platia search by category, negotiate on pricing, request quotes for bulk orders, and verify seller credibility before purchasing. The purchase flow is not linear -- it is conversational. A hotel buying 200 chairs is not going to click "Buy Now." They are going to message the seller, negotiate, request a sample, and then place a purchase order.

What we built instead:

Quote request system. Buyers submit RFQs (Request for Quotes) with quantity, delivery requirements, and timeline. Sellers respond with custom pricing. This is closer to B2B procurement than e-commerce.
Seller verification layer. Every seller goes through a manual verification process before listing products. We built an admin dashboard that tracks verification status, business documentation, and product quality reviews.
Category-specific product schemas. A chair in the "home" vertical has different attributes than a chair in the "events" vertical. Home furniture needs dimensions, material, condition grade. Event furniture needs rental availability, setup/breakdown logistics, and bulk pricing tiers. We modeled these as separate schema extensions rather than a single flexible schema.

The tradeoff: this approach is harder to maintain. Each vertical has its own product model, listing flow, and search configuration. A generic marketplace would be simpler to build but would fail on usability for either buyers or sellers. We chose vertical-specific UX over engineering simplicity.

Self-Service Seller Onboarding

350+ sellers did not happen by accident. We needed a self-service onboarding flow that did not sacrifice quality. The architecture challenge: how do you let anyone sign up and list products while maintaining a trust layer for buyers?

The solution was a staged onboarding pipeline:

Registration. Seller provides business information (RFC, business name, category). Basic validation runs immediately.
Verification. Admin reviews documentation. This is a manual step -- we decided against full automation because trust is the product in B2B marketplaces.
Product listing. Verified sellers can list products. Each listing goes through a lightweight review queue before going live.
Performance tracking. Once live, sellers accumulate a trust score based on transaction completion rate, buyer reviews, and response time.

The data model supports this pipeline:

Seller {
  id: UUID
  businessName: string
  rfc: string
  verificationStatus: 'pending' | 'verified' | 'rejected'
  trustScore: number (0-100)
  verticals: Vertical[]
  products: Product[]
  donations: Donation[]
}

Product {
  id: UUID
  sellerId: FK
  vertical: 'home' | 'events' | 'hotels' | 'restaurants'
  schema: JSONB (vertical-specific attributes)
  conditionGrade: 'A' | 'B' | 'C'
  quantity: number
  pricePerUnit: number
  donationEligible: boolean
}

The vertical-specific schema field uses JSONB rather than rigid columns. This was a deliberate tradeoff: we lose some query optimization but gain the flexibility to support different product types without schema migrations every time a new attribute is needed. For a marketplace at our current scale, this is the right call. If we reach 50,000+ listings, we may revisit with a more structured approach.

Impact Dashboard: Tracking $500K+ in Donations

The impact dashboard is not a reporting afterthought -- it is a first-class feature. Sellers and buyers both see real-time donation tracking. The system needs to aggregate data across transactions, calculate donation amounts, and present them in a way that is auditable and credible.

Architecture for impact tracking:

Event sourcing for donations. Every donation is recorded as an immutable event. We do not update donation records -- we append new events (created, verified, disbursed, confirmed). This gives us a full audit trail.
Materialized view for dashboards. The dashboard reads from a pre-computed aggregation table that updates on a schedule (every 15 minutes). This avoids expensive real-time aggregations on every page load.
Webhook integration with payment processors. When a transaction completes, a webhook triggers donation calculation. The system computes the donation amount (configurable percentage of transaction value) and creates the donation record.

The donation flow:

Transaction completes
  -> Webhook fires
  -> Donation calculator runs
  -> Donation record created (status: pending)
  -> Admin verification queue (for amounts > $10,000 MXN)
  -> Donation confirmed
  -> Disbursement scheduled to nonprofit
  -> Dashboard aggregation updated

We initially tried real-time aggregation for the dashboard. It was slow. Querying millions of transaction records to compute running totals on every page load caused noticeable latency. The materialized view approach reduced dashboard load time from 2.3 seconds to under 200 milliseconds. The 15-minute staleness is acceptable because donation amounts do not change in real-time.

Category Discovery Across Four Verticals

Four verticals (home, events, hotels, restaurants) means four different product taxonomies, four different buyer personas, and four different search strategies. The architecture needs to support vertical-specific discovery without duplicating the entire platform.

Search architecture:

Elasticsearch with vertical-specific analyzers. Each vertical has its own index with custom mappings. Home furniture search prioritizes material and dimensions. Hotel equipment search prioritizes quantity and delivery logistics. Event supplies search prioritizes availability dates and setup requirements.
Faceted navigation per vertical. The filter sidebar changes based on the active vertical. Home buyers see filters for material, color, and condition. Hotel buyers see filters for quantity, delivery timeline, and bulk pricing.
Cross-vertical discovery. Buyers can browse across verticals when searching for general categories (e.g., "furniture" appears in both home and events). We handle this with a unified search index that tags results by vertical, letting buyers filter or expand their search scope.

The tradeoff here is index management complexity. Maintaining four separate vertical indices plus a unified cross-vertical index means more infrastructure and more operations overhead. The alternative (single index with vertical field) would be simpler but would degrade search quality because each vertical needs different relevance scoring.

Trust Layer for Business Buyers

B2B buyers need more trust signals than star ratings. Our trust architecture includes:

Seller verification badges. Verified businesses get a badge visible in search results and listings.
Transaction history. Buyers can see how many transactions a seller has completed, total volume, and average response time.
Condition grading. Every product listing includes a condition grade (A, B, C) with standardized criteria. Grade A is like new. Grade B shows minor wear. Grade C is functional but shows significant use.
Dispute resolution. The platform includes a lightweight dispute flow where buyers can flag issues within 48 hours of delivery. Sellers have 72 hours to respond. Escalation goes to Platia admin.

We debated building a full escrow system. We decided against it for the initial launch. Escrow adds significant complexity (payment holds, release conditions, dispute triggers) and was not blocking our core use case. Sellers and buyers on Platia tend to establish ongoing relationships -- the first transaction might go through the platform, but repeat orders often happen directly. This is realistic for B2B in Mexico, and the architecture accommodates it.

Tech Stack

The technology choices were driven by team composition, timeline, and the need for rapid iteration.

Frontend:

React 18 with TypeScript. The team had deep React experience. TypeScript was non-negotiable for a codebase this size.
TanStack Router. File-based routing with type safety. Better than React Router for complex nested layouts, which a marketplace with four verticals requires.
Tailwind CSS. Rapid UI development without design system overhead. For a marketplace with many pages, Tailwind let us ship consistent UI without a dedicated design team.
React Query (TanStack Query). Server state management. Critical for a data-heavy marketplace where product listings, search results, and dashboard data need caching, background refetching, and optimistic updates.

Backend:

Node.js with Express. Chosen for team expertise. The team was most productive in TypeScript end-to-end.
PostgreSQL. Relational data with JSONB for vertical-specific product schemas. We considered MongoDB for the flexible schema but decided PostgreSQL gave us better query capabilities for the reporting and dashboard features.
Elasticsearch. Dedicated search engine for product discovery. PostgreSQL full-text search was not sufficient for the faceted, vertical-specific search we needed.
Redis. Session management, caching for hot queries (product listings, search results), and rate limiting.

Infrastructure:

Docker containers on a VPS. We started with a single VPS for the MVP. As traffic grew, we moved to a multi-container setup with Docker Compose. This was pragmatic -- we did not need Kubernetes complexity at our scale.
Cloudflare for CDN and DDoS protection. Static assets, API caching, and security layer.
GitHub Actions for CI/CD. Automated testing and deployment on every push to main.

Why not serverless? For a marketplace with complex state management, real-time features (quote negotiations), and heavy search queries, serverless would have introduced latency and debugging complexity that outweighed the scaling benefits. Containers gave us predictable performance and simpler debugging during the critical early growth phase.

Lessons Learned

What we would do differently:

Build the admin dashboard first. We built the seller and buyer experiences first, then had to retrofit the admin tools for verification, dispute resolution, and donation management. The admin dashboard should have been the first thing we built because it defines the operational workflows that the platform supports.
Invest in search earlier. We started with PostgreSQL full-text search and migrated to Elasticsearch after launch. The migration was painful -- we had to rebuild indexes, update query logic, and retrain the team. If search is core to your marketplace, start with a dedicated search engine.
Schema validation on product listings. We allowed too much flexibility in early product listings. Some sellers uploaded incomplete or inconsistent data. Adding stricter schema validation per vertical would have reduced the cleanup work we had to do later.

What worked well:

Vertical-specific product models. The JSONB schema approach for product attributes was the right call. It gave us flexibility without schema migration overhead. Each vertical can evolve independently.
Materialized views for dashboards. Pre-computed aggregations with periodic refresh is the correct pattern for reporting dashboards. Real-time aggregation is a trap for marketplaces with growing transaction volumes.
Staged onboarding with manual verification. The manual verification step slowed seller onboarding but maintained quality. In B2B marketplaces, trust is the product. Automating verification too early would have degraded the buyer experience.
Event sourcing for donations. Immutable donation events gave us a complete audit trail. When donors or nonprofits asked for transaction history, we could reconstruct the full timeline without additional instrumentation.

Results

The architecture decisions are validated by the numbers:

2,000+ products listed across four verticals (home, events, hotels, restaurants)
350+ active sellers onboarded through the self-service pipeline
$500,000+ donated to verified nonprofit organizations
4 verticals operating with vertical-specific product schemas and search
platia.com.mx live and serving B2B buyers across Mexico

The platform is processing transactions, tracking donations, and scaling without major architectural changes. The initial decisions -- PostgreSQL with JSONB, Elasticsearch for search, materialized views for dashboards, event sourcing for donations -- have held up.

What We Would Tell Other Marketplace Builders

If you are building a B2B marketplace, here is the architecture advice we would give based on the Platia experience:

B2B is not B2C with bigger carts. The buyer flow, trust requirements, and negotiation patterns are fundamentally different. Do not try to adapt a B2B2C marketplace framework. Build for your specific buyer behavior.
Start with one vertical, then expand. We launched with two verticals (home and events) and added hotels and restaurants after validating the core architecture. Adding all four at once would have been a mistake.
Invest in the admin dashboard on day one. Operational workflows define what the platform can and cannot do. Build the admin tools first, then build the buyer and seller experiences around those workflows.
Choose PostgreSQL over MongoDB for marketplaces. The relational integrity, JSONB flexibility, and reporting capabilities of PostgreSQL are better suited to marketplace data models than MongoDB's document model.
Dedicated search from the start. If product discovery is your core value proposition, do not use database full-text search. Elasticsearch or Meilisearch will save you migration pain later.
Event sourcing for financial records. Any feature involving money (donations, transactions, payouts) benefits from immutable event logs. The audit trail is worth the complexity.

Building a B2B marketplace? Book a call with our team. We have shipped platforms like Platia and we can help you make the right architecture decisions for your specific market.