Marketplace Evaluation Example: Test Both Sides Before Building

Proposed idea: RepairMatch

RepairMatch is a fictional service matching apartment residents with local appliance repair technicians. The proposed revenue is a fee per completed job. No residents or technicians have been interviewed and no jobs have been booked. This is an editorial worked example, not actual Idea OS output or a customer case study.

Initial assumptions

Residents struggle to find a suitable technician quickly. Technicians want additional jobs and will accept the proposed fee. Enough providers are available in the same area at the same time. None of these statements has been verified.

Evaluation: the two-sided risk

A resident waitlist does not demonstrate provider availability. A provider directory does not demonstrate paid demand. The critical early question is whether a suitable resident request and a willing technician can be matched reliably in a narrow area.

Existing directories, local recommendations, and direct booking are alternatives to investigate. Do not claim a marketplace is cheaper, faster, or safer without evidence. Market size requires sourced counts of relevant jobs, not the population of an entire country.

Change the proposed scope

Before building an app, narrow the pilot to one appliance category and one neighborhood. Manually coordinate requests with willing technicians. Explain fees, responsibility, cancellations, and the pilot's limitations clearly. Check relevant local requirements before arranging work.

Proposed experiment

Recruit five eligible technicians and invite ten residents with a current, relevant repair need to request a quote. Log availability, accepted quotes, completed jobs, cancellations, fees, and support time. These are proposed sample sizes, not observed results.

An illustrative continuation threshold is at least four completed jobs within two weeks, with a technician accepting the disclosed fee and positive contribution after direct costs on each completed job. This small threshold is a learning rule, not a general marketplace benchmark.

Decision branches

• Requests but no available providers: revisit provider recruitment, coverage, or scheduling.
• Available providers but few accepted quotes: investigate urgency, trust, price, and alternatives.
• Completed jobs with excessive support costs: review the process and economics before expanding.
• Threshold met: repeat the pilot and investigate repeat demand; do not infer scale from four jobs.

Evidence status and next step

No outcome has been observed. The current decision is to investigate matching and economics before building a marketplace application. Use the hypothesis worksheet to define both sides and the validation-plan guide to record results.