Marketplace MVP: prove the first successful match

A marketplace MVP should test whether a specific buyer can find a suitable provider and complete a useful transaction. A large directory of profiles does not establish that result. Start with one service, one audience and a clear definition of a successful match before expanding into more categories.

1. 01

   Consider a marketplace for small businesses hiring a photographer. A buyer needs to explain the assignment, location, timing and expected deliverables. A provider needs enough information to decide whether to respond. The first product decision is not how many filters to offer; it is what makes a request specific enough for a useful response.

2. 02

   Write a match contract in plain language. For this example, a successful introduction means an available photographer receives a suitable brief, responds within the agreed window and reaches a clear decision with the buyer. An accepted introduction and a completed assignment are different outcomes. Record both rather than counting every contact-button click as success.

3. 03

   Begin with a small, deliberately recruited provider group. Confirm which assignments each provider accepts and how availability will be checked. Manual review can be appropriate in the pilot, provided the founder records who reviews each request and what happens when no provider is suitable. An empty result needs a useful next step, not an invented listing or a promise the team cannot fulfill.

4. 04

   Build a request state model before adding messaging features. A request might be submitted, clarified, offered to a provider, accepted, declined or closed. Specify who can make each transition. If a provider declines, decide whether the buyer must approve a different introduction. Prevent repeated submissions from creating several identical requests, and give staff a way to explain why a request was closed.

5. 05

   Keep the initial revenue experiment explicit. A listing fee, an introduction fee and a fee on completed work test different forms of value. Do not choose one simply because a payment button is easy to implement. Establish when a fee is earned, what happens when an assignment is cancelled and who handles a disputed outcome before automating collection. Specialist advice may be needed for the intended payment arrangement and operating markets.

6. 06

   Review the whole funnel: valid requests, requests with a suitable response, accepted introductions and completed assignments. Record elapsed time and reasons for failure. Ten accepted introductions from ten carefully selected requests are not comparable to ten from a hundred unsuitable ones. Separate changes in request quality from changes in provider responsiveness.

7. 07

   For the next sprint, fix the most frequent barrier in that sequence. If briefs are unclear, improve intake. If suitable providers are unavailable, work on supply. If accepted introductions rarely become completed assignments, interview both parties about the handoff. More profiles and categories should follow evidence that the narrow marketplace can complete its core promise.