Marketplace Validation: What to Prove Before You Build

Before commissioning a marketplace, test whether you can help a specific buyer find suitable supply, complete the intended transaction, and support it at a cost the business can sustain. A waitlist can show interest; it does not establish that the transaction will work.

This guide outlines a practical framework to surface the assumptions that require proof. The goal is to determine what evidence justifies scoping a small software release, and when you should keep testing, narrow your focus, or stop entirely.

For perspective on how these early decisions impact your required budget, review the true cost of building a marketplace.

Step 1: Define a Narrow Buyer and Supplier Use Case

We recommend testing a narrow buyer and supplier use case. Instead of targeting a broad category like "local home services," define a specific transaction like "emergency HVAC repairs for independent restaurants."

Specific definitions allow you to identify exactly who to interview and precisely what supply you need to aggregate. Testing a narrow segment helps you assess whether you can achieve density in one specific area, directly addressing the chicken-and-egg problem.

Step 2: Map Recent Behavior and Current Alternatives

To validate the problem, recruit people who recently faced the problem and suppliers who serve that need. Record how you found them; a convenient group of friends may not represent the market.

The Nielsen Norman Group's user-interview methodology emphasizes exploring specific past behaviors and avoiding leading questions to uncover reliable qualitative insights. Distinguish clearly between recalled behavior (what they say they did) and observed behavior (what you can verify they actually do).

Focus your interviews on non-leading questions:

• The last occurrence: "Tell me about the last time you experienced this specific situation."
• The actual workaround: "Step by step, what did you do to resolve it?"
• The cost and time: "How much time did that process take, and what was the exact financial cost?"
• The decision maker: "Who ultimately approves the budget for this workaround?"

Step 3: Assess Relevant Supply and Monetization Models

Assess whether the necessary suppliers exist in your target market and evaluate their capacity and willingness to participate.

You must also test how the platform will generate revenue. While commissions are common, you do not have to require every supplier to pay a percentage of the transaction. Who pays—and whether the model relies on a commission, a subscription, a lead fee, or another structure—remains testable. A lack of margin for a commission does not inherently invalidate all marketplace models if buyers or suppliers will pay for access or matching in other ways.

Step 4: Run Manual Matching

Where the workflow allows it, test matching manually before commissioning the full software. If a technical constraint is the main unknown, a small prototype may be the more useful test. Operate with transparency: tell buyers and suppliers that you are personally facilitating the match. Do not use deceptive preorders.

Set an explicit, capped learning budget for this phase. You may need to subsidize early transactions or invest significant unbilled operator time to facilitate matches.

Note on trust and data: Collect only the information the test needs and obtain clear permission before sharing it for coordination. Do not claim supplier qualifications, licenses, or trust metrics to buyers beyond the checks you have actually performed.

Step 5: Track Match Attempts Rigorously

As you run manual matches, track outcomes rigorously against a defined cohort and time window (e.g., "Requests in October"). Prevent duplicate counting of the same request, and record cancellations and refunds separately from successful completions.

Keep a log with meaningful denominators:

• Requested: Total number of unique buyer inquiries in the cohort.
• Feasible Match: How many of those inquiries had available, relevant supply (Feasible / Requested).
• Accepted: How many matches were accepted by both parties (Accepted / Feasible).
• Completed: How many transactions were successfully fulfilled (Completed / Accepted).
• Cancellations/Refunds: How many accepted matches were reversed.
• Repeat attempts: How many participants returned among those eligible and observed for the relevant buying cycle. Keep buyer and supplier counts separate; one-off purchases may not require repeat use.

Step 6: Estimate Contribution

Estimate the contribution of a single transaction by mapping your assumptions. Separate the Gross Transaction Value (GTV) from your platform revenue.

Below is a purely hypothetical arithmetic example with invented inputs to illustrate the calculation.

Hypothetical transaction (invented USD inputs, not provider prices):

• Gross Transaction Value (GTV): $500.00 (Paid by Buyer)
• Platform Revenue (e.g., 10% take rate): $50.00

Deduct Direct Variable Costs:

• Assumed Flat Payment Cost: -$12.00
• Assumed Operator Time/Support: -$20.00
• Assumed Refund/Dispute Risk Allocation: -$5.00

Estimated Contribution Amount: $13.00 per transaction. Estimated Contribution Margin: 26% ($13.00 / $50.00 platform revenue).

This is contribution, not profit. Product development, fixed staff, acquisition and other overhead may still need funding. Document exclusions and avoid counting the same refund as both reduced revenue and a separate expense.

Then record when money is collected, paid out or returned. Compare a less favorable scenario as well; a small pilot with subsidized operator time does not establish sustainable economics.

Step 7: Document Trust and Operations Needs

Document every operational requirement necessary to facilitate trust. Note what credentials suppliers provided and how disputes over quality were handled.

Understanding these requirements directly influences your MVP feature planning. If a transaction inherently requires manual vetting or heavy compliance checks, you must factor those operations into your platform choice.

The Validation Decision Table

Use this copyable table to document your ongoing validation evidence:

Base your next step on your critical unknowns:

• Proceed: You have documented evidence supporting your core assumptions, and critical unknowns are bounded. This does not mean universal readiness; it means you are justified in scoping a small next release or software test. Evaluate your technical approach using our WordPress vs. Custom Platform Guide.
• Narrow: You found traction, but only within a very specific subset of your test. Constrain your use case further and test again.
• Retest: You lack conclusive data on a critical component. Run a new test specifically targeting that unknown.
• Stop: You discovered a critical failure point that breaks the model. Stop here and save your budget.

Next Step: Complete the Validation Workbook

To organize your evidence, download the printable Marketplace Validation Workbook (PDF).

Use its five sections to define the next test, record buyer and supply evidence, log matching outcomes, estimate contribution, and choose the next action. Name an owner and review date. Copy the interview page when you need more space. The PDF can be printed or annotated; it has no interactive form fields or automatic calculations. There is no numeric readiness score.

Directorism designs and builds marketplaces and directories for clients. Documented evidence gives a technical partner a useful starting point for defining what the first release must do, what can stay manual, and what still needs testing.