Build the work between the buyer and the seller.
From the outside a marketplace looks like a listing site. Underneath it is several products at once, and the one your own team uses decides whether the others keep working.
Different people, different screens.
Sellers and providers
They sign up, submit documents, create listings, set prices and availability, accept orders and track payouts. If onboarding is painful, supply never arrives.
Buyers
They search, compare, ask questions and pay. They need to know who they're buying from, what happens next and what to do if it goes wrong.
Your team
You approve sellers, moderate listings, hold or release funds, handle cancellations and settle disagreements. This view often gets left for later, and it shouldn't.
Picture a platform connecting home-repair technicians with households. The first version gets search and checkout right. Then a technician doesn't show up, a customer wants half the money back, and the founders are working the case from a WhatsApp chat and the payment provider's dashboard. Without an operations view, every exception turns into a manual investigation.
That's why we design the operational side from the first release. It doesn't need to be elaborate. It needs to show each transaction's state on both sides, let your team act on it, and keep a record of what they did. Approvals, payment states and support cases belong in the core product.
We also ask you to narrow the first version. One category, one kind of transaction and one audience is easier to get right, and the evidence it produces tells you where to expand. Usually that's a better plan than launching every category at once.
Trace one order, then break it.
Start with how a successful transaction happens today, even if it's done by hand.
The buyer orders
What does the buyer commit to, and is payment taken now, held, or collected later?
The seller accepts
How long can the seller take to respond, and what happens to the buyer's payment if they decline or go quiet?
Fulfilment
Who confirms delivery or completion: the buyer, the seller, a time limit, or your team?
Money moves
When is the seller paid, what fee does the platform keep, and how is it recorded? Our payments and billing page covers how payment events are tracked.
Then cancel it
Run the same order with a cancellation or a dispute. The record both sides see, and the one your team sees, should explain exactly what happened.
Settle these with your team.
- Whether sellers need approval before their listings go live, and what documents that review checks.
- Who holds the buyer's money between order and fulfilment, and whether your payment provider supports that.
- The fee model: commission, listing fees, seller subscriptions, or a mix.
- Who handles disputes, how evidence is collected, and which decisions your team can make.
- What buyers and sellers can see of each other before and after a transaction.
- Which rules differ by category, so the first category doesn't hard-code assumptions for the rest.
Marketplace founders often ask.
Should the first version cover every category?
Rarely. A clear transaction for a clear audience teaches you more, and it keeps the operations view small enough for your team to run well. New categories can follow once you've seen how the first one behaves.
Can we approve sellers before they go live?
Yes. We can build a review step where your team checks documents and listings, asks for changes, and decides when a seller becomes visible to buyers. Publication rules can differ by category.
Do we need mobile apps from day one?
Not necessarily. A well-built mobile web version often serves both sides at launch. Native apps make sense when sellers need features like offline use or frequent push alerts, and that's a decision for your evidence, not ours.
Useful next pages.
Describe your first transaction.
Tell us who buys, who sells and where the money sits, and we'll help scope a sensible first release.