Marketplace MVP: What to Build First (And What to Skip)

The most expensive mistake a marketplace founder can make is building too much before they have validated anything. I have seen founders spend eight months and $150,000 building a marketplace with advanced search filters, a sophisticated review system, a messaging layer, a dispute resolution workflow, and a custom payment integration — only to discover at launch that the fundamental supply-demand match did not exist.

The problem is that "build an MVP" is advice that gets misapplied in marketplace contexts. The standard SaaS MVP playbook does not translate. A SaaS MVP is the smallest version of a product that delivers core value to one user. A marketplace MVP is the smallest version of a platform that can facilitate a real transaction between two parties who would not otherwise have found each other.

Those are very different things. And getting clear on what you actually need — and what you absolutely do not — is the difference between launching in six weeks and burning six months.

The right question to start with

Before you build anything, ask: "What is the minimum I need to facilitate one real transaction between a buyer and a seller?"

Not a demo transaction. Not a simulated one. A real transaction where money changes hands, a service gets delivered, a product gets shipped, or a rental takes place — and both parties are satisfied enough to consider doing it again.

That is your target. Work backwards from it. Everything that is required to reach that first real transaction belongs in your MVP. Everything else does not.

What a marketplace MVP must have

Supply listings

Buyers cannot transact without something to transact with. Your MVP needs a way for supply to exist on the platform — whether that is seller profiles, product listings, service offerings, or rental inventory. The information does not need to be rich. It needs to be sufficient for a buyer to make a decision.

At minimum: a title, a description, a price, and a way to contact or book the provider. That is often enough. Photography, embedded video, detailed specifications, and comparison features can come later.

Buyer discovery

Buyers need to be able to find relevant supply. This does not require advanced search, AI-powered recommendations, or sophisticated filtering. It requires that a buyer who arrives with a specific need can find listings that match it.

In the very early stages, discovery can be as simple as a category browse and a basic keyword search. For many marketplaces, a well-organised listing page with a few filters is entirely sufficient for the first hundred transactions.

A transaction mechanism

Your platform needs to facilitate the actual transaction — whether that is a booking, a purchase, an enquiry that converts, or a request that gets matched. This does not need to be fully automated.

Some of the most successful early-stage marketplace workflows I have seen were partly manual. A buyer submits a request. An operator reviews it and manually matches a provider. The provider confirms. Payment is collected through Stripe. The automation came later, once the manual process had proven the model worked.

Payment processing

Money has to change hands on your platform. This is non-negotiable — not because you need the revenue on day one, but because payment on-platform is what makes it a marketplace rather than a directory. Use Stripe, or a payment infrastructure layer built on Stripe Connect for two-sided platforms. Do not build custom payment processing. It is not a differentiator and it is not something to own in the MVP phase.

Basic trust signals

New buyers need enough information to feel comfortable transacting with a stranger. This does not require a sophisticated trust architecture at launch. It requires the basics: verified seller identity (even just email verification), a clear refund or cancellation policy, and responsive support.

The review system comes after transactions happen, not before. You cannot pre-populate reviews. Launch without them and collect them from your first users.

What your marketplace MVP does not need

This list is more important than the previous one, because scope creep in this direction is where founders lose months.

• Advanced search and filtering. You do not have enough supply for filters to be useful at launch. Basic search is sufficient until you have enough listings that filtering becomes necessary to find relevant results.
• A review system. You have no reviews yet. Build the collection mechanism, but do not invest heavily in review display, response workflows, or review analytics until you have a corpus of actual reviews to work with.
• A sophisticated messaging system. Email-based notifications and a basic inbox are sufficient for most early-stage marketplaces. An integrated chat layer with file sharing, read receipts, and structured templates is a later-stage product.
• Automated dispute resolution. Handle disputes manually at first. You will learn what your actual dispute patterns look like before you build a system to manage them. Building a workflow for problems you have not yet encountered is wasted investment.
• A mobile app. A responsive web application is sufficient for launch unless your specific use case is inherently mobile-first (e.g., a gig economy platform where providers need push notifications to respond to jobs in real time). Mobile apps are expensive to build, maintain, and iterate on. Validate on web first.
• Analytics dashboards for sellers. Your first sellers do not need dashboards. They need transactions. Build seller analytics when retention becomes your primary concern.
• Referral programs, loyalty features, or gamification. These are retention mechanisms. You do not have a retention problem yet. You have an acquisition and liquidity problem. Solve those first.

The concierge phase comes before the MVP

Before you build anything, there is a phase that is even more minimal than the MVP. I call it the concierge phase. It is the stage where you manually do everything the platform will eventually automate — to prove that the underlying market actually works.

This means recruiting supply by hand, manually connecting buyers with providers, facilitating the transaction yourself if necessary, and collecting payment through the crudest mechanism available (a Stripe payment link, an invoice, a bank transfer). If you can get five to ten transactions completed in this mode, you have validated that the market exists before spending a cent on product.

The idea validation process and the MVP are related but distinct. Validation tells you the market exists. The MVP is the smallest platform that can serve that market without you being in the middle of every transaction.

Do not skip the concierge phase in your rush to build the MVP. The two to four weeks you spend facilitating transactions manually will tell you more about what your platform actually needs to do than any product discovery workshop.

Platform choice and build time

Choosing the right platform is the single biggest lever on how fast you can reach your MVP. A marketplace built on Sharetribe Flex can be live in four to eight weeks with a focused team. A custom build takes four to eight months at minimum, and usually longer.

Unless you have a specific technical requirement that Sharetribe cannot meet — and most early-stage founders do not — a platform-based MVP is almost always the right call. The goal at this stage is to validate the market, not to build a technical asset. You can rebuild on custom infrastructure once you know what you are building and why.

For a full breakdown of when platform versus custom makes sense, see the Sharetribe vs alternatives comparison.

The one metric that tells you the MVP is working

Once your MVP is live, there is one metric that tells you more than anything else: are buyers who transact once coming back to transact again?

First-transaction repeat rate is the most honest signal that your marketplace is working. It tells you that the experience was good enough to earn a second visit. Everything else — traffic, listings, GMV — can be gamed or misread. Repeat transactions cannot.

If your first-transaction repeat rate is above 40% within 30 days of a buyer's first purchase, you have something worth building on. If it is below 20%, the issue is either liquidity (buyers could not find what they needed) or experience quality (the transaction did not meet expectations). Either way, that is the problem to solve before adding any new features.

The MVP is not the finish line

The marketplace MVP is the beginning of a learning process, not the end of a build process. Its job is to generate real transaction data as quickly as possible, so that every subsequent product decision is based on what users actually do — not what you think they need.

The founders who launch the smallest credible product and iterate based on real data consistently outperform the ones who try to build the perfect marketplace before launch. The market always knows better than the product spec.

Build the minimum that can complete a real transaction. Then learn. Everything else is a distraction until the transactions are happening.