# Should You Build a Marketplace Before You Have Both Sides? > Decide whether a marketplace model is worth building by proving one narrow buyer-seller transaction manually before you add platform complexity. By buildpurdue Team · September 4, 2026 · 5 min read Source: https://www.buildpurdue.org/blog/build-marketplace-before-both-sides --- An empty marketplace is not a product. It is a promise that both sides will eventually show up. Consider Priya, who wants to build a marketplace connecting small restaurants with local food photographers. Restaurants need affordable photos; photographers want paid work. She could spend three months building profiles, search, reviews, messaging, and payments. She could also learn whether anyone will complete one transaction this week with a spreadsheet and two emails. Start with the transaction, not the platform. A marketplace deserves software only after you can make one narrow exchange happen repeatedly enough to learn what the software must support. ## Key takeaways - Prove that a specific buyer and seller both want the same transaction before building a general marketplace. - Narrow the launch to one customer type, one use case, and one reachable group. - Match the first participants manually so you can observe trust, pricing, timing, and failed handoffs. - Treat payments, verification, disputes, and seller risk as part of the business model, not later engineering details. ## Do you have a marketplace or a directory? Priya first writes the transaction in one sentence: “A restaurant pays a photographer to deliver ten menu photos within seven days.” That sentence names the buyer, seller, service, timing, and exchange. It is more useful than “a platform for local creative services.” Then she asks whether both sides need a marketplace at all. A directory can help restaurants find photographers without processing payment or managing the relationship. A marketplace takes on more responsibility: customers may pay the platform, sellers may need onboarding and verification, and the platform may need to handle refunds, disputes, and negative balances. [Stripe’s marketplace documentation](https://docs.stripe.com/connect/marketplace) describes those responsibilities alongside the mechanics of collecting customer payments and paying connected sellers. That distinction changes the first test. If a curated list and an introduction create the value, build a directory or service first. If the difficult problem is reliably matching, transacting, and coordinating both sides, a marketplace may eventually be justified. Do not choose the heavier model because it sounds more venture-scale. ## Start with one narrow match Priya should not launch across an entire city. She chooses independent restaurants opening or refreshing a menu in one neighborhood and photographers who already shoot food. The smaller market makes the empty-room problem manageable and gives her a chance to learn the same workflow more than once. She interviews each side separately. Restaurants describe the last time they bought food photography, what they paid, how long it took, and what went wrong. Photographers explain which jobs they accept, how they price them, and what makes a client worth the effort. She is looking for a real job on both sides, not general excitement about the concept. [Sharetribe’s marketplace validation guide](https://www.sharetribe.com/academy/how-to-validate-your-marketplace-idea-before-building-the-platform/) recommends testing demand on both sides with interviews, landing pages, and manual matching before building the platform. The useful lesson is not a universal interview count. It is that a marketplace has two separate customers whose incentives and objections must both be understood. Priya can now run the first version with a form, a spreadsheet, and a short agreement about scope. She introduces three photographers to five qualified restaurants, stays close to the conversations, and records what happens: who replies, what each side expects, whether the price is acceptable, how long a match takes, and why anyone walks away. ## Measure liquidity before adding features The first question is not how many people sign up. It is whether the right people can find a workable match within a reasonable time. A marketplace with 500 profiles and no completed exchange has less evidence than one that completes five small transactions. Priya sets a bounded test: over four weeks, she wants ten qualified restaurant requests, five completed introductions, and three paid shoots. Those are planning thresholds, not industry benchmarks. She also records the effort required to create each match. If every transaction needs her to rewrite the brief, negotiate the price, and chase both parties, the workflow may still be valuable, but it is not ready for broad automation. YC’s discussion of network effects notes that successful marketplaces often focus on demand first and narrow the initial problem. [The interview with Anu Hariharan](https://www.ycombinator.com/blog/anu-hariharan-on-network-effects/) gives Priya a practical question: which side is easier to build first, and what does that side need from the other one immediately? She should choose the side that creates a credible reason for the other side to participate, not split her attention evenly by default. Only after repeated matches should Priya decide what to build. If customers repeatedly struggle to describe the job, she may need a structured brief. If photographers miss deadlines, she may need availability and delivery expectations. If payment creates trust problems, she may need a transaction flow. Each feature should remove a repeated failure from a proven exchange. ## Know when the platform is earned Marketplace software adds obligations as well as convenience. Before processing payments, Priya must understand seller onboarding, identity checks, refunds, disputes, taxes, and who carries the risk when a transaction goes wrong. A technically smooth checkout cannot fix a weak market or unclear responsibility. The right next move is small: write one buyer-seller transaction, recruit a few people on each side, and manually complete the exchange. Count completed transactions, time to match, money exchanged, failed handoffs, and the work you had to perform yourself. Build the smallest tool that removes the same bottleneck three times. If you want peers to pressure-test the workflow, bring the experiment to the [buildpurdue cohort](/cohort).