What Was Built: The Two-Sided Marketplace MVP Architecture
The marketplace MVP architecture that works at early stage consists of five layers. The first is a supply-side profile and listing system: a structured onboarding flow for the supply side of the marketplace (service providers, sellers, hosts, or practitioners depending on the domain) that collects the information demand-side users need to make a booking or purchase decision, with a verification step that provides a minimum trust signal even at MVP stage. The second is a discovery and matching layer: a search and filter interface for the demand side that allows meaningful browsing and discovery of supply-side listings, with a matching algorithm that at MVP stage can be as simple as relevance-ranked keyword and category filtering rather than a full ML recommendation engine. The third is a transaction and communication layer: the ability for demand-side users to express intent (enquire, book, or purchase), for supply-side users to respond, and for the transaction to complete, with a messaging thread that keeps communication within the platform rather than pushing it to email or WhatsApp where it immediately exits the marketplace ecosystem. The fourth is a payments layer: Stripe Connect in the marketplace configuration, which handles split payments between the platform and the supply-side participant, escrow timing for service-based transactions, and platform commission capture without the legal and financial complexity of building a custom payment flow. The fifth is a trust layer: a review and rating system for both sides of the marketplace, and a minimum viable identity verification step for supply-side participants that provides a credibility signal to demand-side users even before the marketplace has accumulated the transaction volume that makes reviews meaningful.
The Cold Start Strategy Must Be an Architecture Decision
The cold start problem is not solved by marketing, it is solved by architecture. Marketplaces that attempt to launch with an empty supply side and drive demand-side traffic to an empty platform die in the first month regardless of how much they spend on acquisition. The architectural approaches that have worked at scale fall into three patterns. The first is a constrained geography or vertical launch: the marketplace is initially available only in a single city, sector, or use case where supply-side density can be achieved with a small number of participants. The MVP architecture must enforce this constraint through location filtering, allowing the product to surface a full and compelling supply catalogue within the constrained scope. The second is a managed supply bootstrap: the marketplace team acts as the supply side directly for the first cohort of transactions, either by providing the service themselves or by operating as an intermediary who fulfilment-guarantees the experience, before transitioning to a true marketplace model once demand patterns are understood. The third is an aggregation-to-marketplace evolution: the product launches as a directory or aggregator without transaction functionality, builds supply-side relationships and demand-side traffic, and introduces transaction capability once both sides have established presence. Each of these strategies has specific implications for the MVP feature set and data model.
Tech Stack Used
The two-sided marketplace MVP stack consists of Next.js for the consumer-facing frontend and the supply-side dashboard, Supabase for the database and authentication layer with row-level security separating supply and demand user data, Stripe Connect in the marketplace account configuration for split payments, escrow, and platform commission, Mapbox or Google Maps for location-based listing discovery, Algolia or Supabase Full Text Search for listing search and filtering at MVP volume, Resend for transactional email covering booking confirmations, enquiry notifications, and review requests, Uploadcare or AWS S3 for listing photography and supply-side asset management, and a lightweight messaging system built on Supabase Realtime for in-platform communication. For marketplaces with a service rather than product transaction model, Calendly API or a custom availability management module handles the scheduling layer. Identity verification for supply-side participants at MVP stage uses Stripe Identity, which integrates with the existing Stripe Connect onboarding flow and provides document and selfie verification without a separate third-party contract.
Trust and Safety: The Non-Negotiable MVP Investment
Trust and safety is the layer that most marketplace MVPs defer and consistently regret. The minimum viable trust layer for a marketplace has three components. The first is identity verification for supply-side participants: without a basic identity check, a single high-profile bad actor can destroy marketplace trust irreparably at early stage. Stripe Identity integration during supply-side onboarding provides government ID verification in a single API workflow. The second is review integrity: a review system that allows reviews only from verified transaction participants, displayed prominently on supply-side profiles, creates the trust signal that allows demand-side users to transact with unfamiliar supply-side participants. The third is a clear dispute process: even at MVP stage, the platform needs a defined process for handling transaction disputes. This does not need a dedicated trust and safety team, but the process needs to exist in writing, be linked from the payment confirmation, and have a response time commitment. Platforms that defer dispute resolution design until they have their first major dispute consistently handle it badly under pressure, which damages the supply-side relationship and creates regulatory exposure.
What to Replicate from This Pattern
The single most valuable practice to replicate is designing the supply-side onboarding experience with the same attention as the demand-side browsing experience. Most marketplace MVPs over-invest in the consumer-facing discovery UI and under-invest in the listing creation experience, resulting in supply-side participants creating thin, incomplete listings that do not convert demand-side users. A well-designed supply-side onboarding wizard that walks participants through every element of a high-converting listing, with preview feedback showing how the listing will appear to demand-side users, consistently produces better listing quality than an open-form approach. The second most valuable practice is wiring the payment layer before launch. Marketplace projects that defer Stripe Connect integration to after launch consistently discover that adding payment rails to an existing data model requires significant refactoring.
What to Avoid
The most common and most damaging marketplace MVP mistake is building a custom payment flow instead of using Stripe Connect. Building split payment logic, escrow, payout management, and commission capture from scratch adds 4-6 weeks to the build timeline and creates ongoing compliance, PCI DSS, and reconciliation overhead. Stripe Connect solves all of these problems for marketplace use cases with a well-documented API. The second mistake is launching simultaneously in multiple geographies or verticals, diluting supply-side density to the point where demand-side users in any single market see an empty or near-empty catalogue. The constraint of a single market launch is uncomfortable for founders but consistently produces the supply density that converts early demand-side users into repeat customers. The third mistake is building a recommendation algorithm before accumulating transaction data. Collaborative filtering and personalisation require transaction history to function. At MVP stage, a well-designed category taxonomy and quality-based sort order consistently outperforms an underpowered ML recommendation system.