Headless marketplace architecture with Next.js on Vercel for ISR-powered storefronts, Supabase PostgreSQL with row-level security for multi-tenant vendor isolation, and Stripe Connect for automated split-pay commission processing. Event-driven inventory pipeline handles 100K+ SKU sync via Supabase Realtime and edge functions, with dedicated search indexing through Algolia or Meilisearch for sub-10ms faceted catalog queries.
Where enterprise projects fail
And "not fine" usually hits around 100K SKUs when you've got multiple vendors trying to sync inventory simultaneously. I've watched Shopify stores grind to a halt, product pages timing out, customers seeing "in stock" on items that sold out three hours ago. That stale stock data isn't just annoying. It's abandoned carts, chargebacks, and angry emails to your support team at 2am. The revenue bleed from slow page loads alone -- Google's own data puts conversion drop-off at 4.6% per additional second -- is enough to justify rearchitecting the whole thing. Honestly, most platforms weren't built for genuine multi-vendor complexity. They were built for one store, one inventory source, one fulfillment flow. Try to bolt on 200 vendors with independent stock feeds and you're fighting the architecture every single day. What makes this so frustrating is that it's not obvious at first. You'll launch on Shopify Plus, things feel fine at 10K SKUs, maybe even at 30K. But somewhere around that 80-100K range -- especially once you've got vendors in different time zones pushing inventory updates overnight -- the cracks appear fast. Pages that used to load in 1.2 seconds start hitting 4 or 5. Your search index falls out of sync. Customers in Sydney are buying stock that a vendor in Toronto already cleared two hours prior. That's not a configuration problem. That's an architectural mismatch between what the platform was designed for and what your business actually needs.
It's not. The split-pay logic alone is manageable -- but then you hit your first multi-currency refund on a disputed order that involved three vendors, and suddenly your "naive implementation" (their words in the docs, not mine) completely falls apart. And here's the real kicker: vendors don't care about your technical debt. They care that their Thursday payout was wrong by $340. Do that twice and they're listing on a competitor's marketplace by Monday.
And when it isn't, it's catastrophic. Vendor A shouldn't be able to query Vendor B's orders, pricing logic, or customer data -- full stop. It's not just a security breach risk. It's a GDPR violation, a SOC 2 audit failure, and the kind of story that ends up on TechCrunch. One exposure event and your entire vendor network evaporates overnight.
But they'll also cap your ceiling. Commission structures are often fixed or barely configurable. Workflows are theirs, not yours. So when your business model evolves (and it will), you're either hacking around platform constraints or staring down a full replatforming project that costs more than building custom did originally.
What we deliver
Enterprise Marketplaces Need More Than a Plugin
Most marketplace platforms start the same way: a team bolts a multi-vendor plugin onto Shopify or WooCommerce, hardcodes some commission logic, and calls it done. It works fine for 50 vendors and 2,000 SKUs. Then the business scales. Inventory sync drifts. Split payments fail silently. Vendor onboarding becomes a manual nightmare. The monolithic frontend can't serve different buyer personas without turning into spaghetti code.
We build custom multi-vendor marketplace platforms from scratch using Next.js, Supabase, and Stripe Connect. These aren't MVPs dressed up as enterprise software. They're production systems built for 100K+ SKU catalogs, real-time inventory sync across vendor feeds, automated split-pay commission structures, and sub-second storefront performance at scale.
Why In-House Teams Stall on Marketplace Architecture
Marketplace development is a fundamentally different beast from single-vendor ecommerce. Your engineering team might be excellent at building product features—but marketplace architecture introduces problems they haven't hit before.
Multi-Tenancy at the Data Layer
Every vendor needs isolated access to their own products, orders, and analytics, while the platform operator needs a unified view across all of them. Row-level security policies, role-based access control, and vendor-scoped API endpoints aren't optional. They're table stakes. Most teams underestimate what it takes to write Postgres RLS policies that actually perform well across 100K+ product rows with vendor-specific attributes.
Payment Splitting That Actually Works
Stripe Connect sounds straightforward in the docs. In production, you're handling Express and Custom connected accounts, managing KYC flows across multiple jurisdictions, calculating tiered commissions that vary by category and volume, processing refunds that split back correctly, and managing payout timing that vendors actually trust. One misconfigured webhook handler and your vendor payouts drift by thousands. We've seen it happen.
Inventory Sync at Catalog Scale
Two hundred vendors, each managing 500 SKUs with variant matrices—that's millions of inventory state changes per day. Real-time sync means Supabase Realtime subscriptions pushing stock changes to the storefront, webhook pipelines reconciling vendor feed updates, and conflict resolution when two systems disagree on available quantity. This is distributed systems engineering, not CRUD.
Frontend Performance With Dynamic Catalogs
A 100K SKU catalog with faceted search, vendor-specific pricing, location-based availability, and personalized recommendations needs more than a basic product grid. You need ISR for catalog pages, edge-cached search results, streaming SSR for personalized content, and a component architecture that doesn't re-render the entire page when a filter changes.
Our Architecture: Headless Commerce Built for Marketplace Complexity
We don't use off-the-shelf marketplace platforms. We compose purpose-built systems from proven infrastructure.
Next.js Storefront Layer
The buyer-facing storefront runs on Next.js deployed to Vercel's edge network. We use Incremental Static Regeneration for catalog pages—100K product pages get statically generated and revalidated on inventory changes, not rebuilt from scratch on every request. Search and filtering run through a dedicated index (Algolia or Meilisearch) with vendor-scoped facets. Multi-vendor cart logic handles split-order orchestration before checkout, showing buyers exactly which items ship from which vendor.
Server Components handle data-heavy pages without shipping unnecessary JavaScript to the client. Route handlers serve as lightweight API endpoints for cart operations and real-time stock checks. The result: Lighthouse scores above 95 on catalogs that'd choke a traditional ecommerce frontend.
Supabase Backend and Data Layer
Supabase gives us PostgreSQL with row-level security, real-time subscriptions, edge functions, and built-in auth—all on infrastructure we can reason about. The data model centers on a multi-tenant schema where vendors, products, orders, and payouts are relationally linked, with RLS policies enforcing tenant isolation at the database level.
Vendor dashboards are built as authenticated Next.js routes that query Supabase directly using the vendor's JWT. They see only their products, their orders, their payout history. Platform admins see everything. There are no application-level permission checks that can be bypassed—the database itself enforces access.
Edge Functions handle webhook processing from Stripe, inventory feed ingestion from vendor systems, and event-driven notifications. Supabase Realtime pushes inventory changes to connected storefronts within milliseconds.
Stripe Connect Payment Orchestration
Every vendor onboards through Stripe Connect Express or Custom accounts, depending on the platform's compliance requirements. Here's our payment flow:
- Buyer checks out with a multi-vendor cart
- We create a PaymentIntent with
transfer_grouplinking all vendor splits - On successful charge, transfers go to each vendor's connected account minus the platform commission
- Commission tiers are calculated from a rules engine stored in Supabase—flat percentage, category-based, volume-tiered, or hybrid
- Refunds automatically reverse the correct proportion to each party
- Payout schedules are configurable per vendor through Stripe's payout API
We handle the edge cases that break most implementations: partial refunds across split orders, disputed charges affecting multiple vendors, currency conversion for cross-border marketplaces, and 1099-K tax reporting thresholds.
Inventory Sync Pipeline
For platforms with 100K+ SKUs across hundreds of vendors, we build an event-driven inventory pipeline:
- Vendor feeds ingest via CSV upload, API push, or webhook from vendor systems (Shopify, custom ERPs, spreadsheets)
- Validation layer checks for duplicate SKUs, missing attributes, pricing anomalies, and image requirements
- Approval workflows route new products through platform review before they go live
- Real-time sync uses Supabase Realtime to push stock changes to the storefront and search index simultaneously
- Conflict resolution handles race conditions when a vendor updates stock while an order is processing
This pipeline processes thousands of SKU updates per minute without blocking the storefront.
Production-Proven at Scale
This isn't theoretical architecture. We've built and operated systems with comparable complexity.
Our NAS directory platform manages 137,000+ listings with structured data, search, and real-time updates—the same catalog-scale challenges marketplace platforms face. Our auction platform handles sub-200ms real-time bid latency, which proves our Supabase Realtime and edge function setup holds up under concurrent write pressure. Our Korean manufacturer hub deploys across 30 languages with localized content, demonstrating the multi-region storefront capabilities enterprise marketplaces need.
Every project ships with Lighthouse 95+ performance scores. We don't trade functionality for speed.
Delivery Model and SLAs
Marketplace builds follow a phased delivery model:
Phase 1 (Weeks 1-4): Foundation Data modeling, Stripe Connect integration, vendor onboarding flow, basic storefront with auth. You have a working marketplace with real payments.
Phase 2 (Weeks 5-10): Scale 100K SKU inventory pipeline, search indexing, commission engine, vendor dashboards, order splitting and fulfillment routing.
Phase 3 (Weeks 11-14): Polish Performance optimization, analytics dashboards, admin tools, monitoring, load testing, and production hardening.
Total timeline: 12-16 weeks for a production marketplace. We work in 2-week sprints with deployable increments. You own the code, the infrastructure, and every Stripe webhook handler.
Why This Stack Over SaaS Marketplace Platforms
CS-Cart, Sharetribe, and Yo!Kart get you to market fast—with rigid constraints attached. At 100K SKUs, 200+ vendors, and custom commission logic, you hit walls: performance degrades, payment customization requires forking the platform, and you're paying rent on someone else's architecture indefinitely.
Our headless stack gives you complete code ownership, infinite customization depth, and infrastructure costs that scale linearly instead of exponentially. When your marketplace model evolves—and it will—you're extending your own system, not waiting on a SaaS vendor's roadmap.
The enterprises that win in marketplace commerce treat the platform as a competitive advantage, not a commodity.
See this capability in action
Frequently asked
How does Stripe Connect handle split payments across multiple vendors in a single checkout?
We create a PaymentIntent with a `transfer_group` that ties all vendor splits to a single charge. Once payment clears, individual transfers go out to each vendor's connected Stripe account -- minus the platform commission, which we calculate at checkout using rules stored in Supabase. Flat rate, tiered by volume, category-specific -- all configurable without a code deploy. And refunds? They automatically reverse the correct proportion back to each party. Not an approximation. The exact right amount.
Can this architecture handle 100,000+ SKUs without performance degradation?
Yes, and here's how it actually works. Product catalog pages use Next.js Incremental Static Regeneration -- pre-built at deploy time, then revalidated on-demand whenever inventory changes rather than hammered fresh on every request. Search runs through a dedicated Algolia or Meilisearch index that handles faceted queries across 100K+ SKUs in single-digit milliseconds. Underlying database queries lean on Postgres indexes and materialized views. The result is a storefront that stays fast under real load, not just in benchmarks.
How do you handle vendor onboarding and KYC compliance?
Vendors onboard through Stripe Connect Express or Custom accounts -- Express is faster, Custom gives you more control over the UX and compliance handling. Stripe manages identity verification, bank linking, and ongoing KYC so you're not touching that liability yourself. We wire the onboarding flow directly into the vendor dashboard with status tracking, document upload, and automated step progression. Platform admins get a review queue before any vendor goes live. Nothing slips through.
What's the timeline and cost for building a custom enterprise marketplace?
Honest timeline for an enterprise marketplace build: 12-16 weeks across three phases. Foundation first -- payments, auth, basic storefront. Then scale -- inventory pipeline, search, vendor dashboards. Then polish -- performance tuning, analytics, monitoring. Investment typically runs $100K to $300K depending on vendor count, how gnarly your integration requirements are, and whether you need custom commission logic or can work with standard tiers. These aren't padded estimates. That's genuinely what it takes to build this correctly.
Why choose a custom headless stack over SaaS marketplace platforms like CS-Cart or Sharetribe?
SaaS platforms are the right call for early-stage marketplaces. Seriously. But they hit a wall -- performance, customization, commission flexibility -- somewhere around 100K SKUs and 200+ vendors. At that scale you need a custom commission engine, vendor-scoped RLS enforced at the database level, and a frontend that doesn't degrade under catalog load. What we build gives you full code ownership, infrastructure costs that scale linearly rather than per-transaction, and zero dependency on a SaaS vendor's product roadmap decisions.
How does real-time inventory sync work across hundreds of vendors?
Vendor feeds arrive in every format imaginable -- API pushes, overnight CSV uploads, webhooks that occasionally duplicate or drop entirely. We build an event-driven pipeline that handles all of it. Updates flow through validation and conflict resolution, then propagate simultaneously to the storefront via Supabase Realtime subscriptions and to the search index. Thousands of SKU updates per minute, processed without ever blocking the buyer experience. That's the architecture working the way it should.
Browse all 15 enterprise capability tracks or compare with our SME-scale industry solutions.
Schedule Discovery Session
We map your platform architecture, surface non-obvious risks, and give you a realistic scope — free, no commitment.
Schedule Discovery Call
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.