The pitch deck makes it look like two CRUD apps stapled together. Sellers list things. Buyers buy things. How hard can a marketplace be. So the first version ships fast, demos well, and falls apart the moment real money and real strangers show up.
A marketplace doesn't fail at its features. The listing page works. Search works. Checkout works. It fails at the seams — the handoffs between supply and demand, between a transaction and the money behind it, between two parties who don't trust each other and have no reason to. Those seams are where the disputes, the chargebacks, the fraud, and the empty-marketplace death spiral all live. Let's architect the parts that actually break.
The core entities, and why "buyer" and "seller" is the wrong model
The first design mistake is modeling the obvious nouns. You write a seller table and a buyer table, and within a quarter you're fighting your own schema, because real marketplaces don't split cleanly along those lines.
The entity that holds up is a participant who can act on either side. On most marketplaces, the same account both buys and sells over its lifetime, or wants to. Model a single participant (or account), and let roles be capabilities a participant holds in a given context, not separate tables. A driver is a rider on the weekend. A freelancer hires another freelancer. Bake "buyer" and "seller" into the identity model and you'll fight it forever.
The other entity that needs first-class status from day one is the transaction as a state machine, not a row. A marketplace transaction is not a purchase; it's a lifecycle: requested, accepted, in progress, delivered, confirmed, disputed, settled, refunded. Each state has allowed transitions, allowed actions per participant, and money consequences. Model this as an explicit state machine, because the moment you treat a transaction as a row with a status string that anyone can set to anything, you've lost the ability to reason about money. The state machine is the marketplace.
Payments and escrow: the marketplace is a money-routing problem
Here's the structural truth: a marketplace is a payments company that also has listings. The hard part isn't taking money. It's holding it, splitting it, and deciding when to release it — and getting any of that wrong is the difference between a business and a liability.
You almost never want money to move buyer-to-seller directly. Direct payment means the platform has no leverage when something goes wrong — the money's already gone, and a dispute is now a refund chase across two strangers with you in the middle and no funds in hand. The architecture that works is escrow: the buyer pays the platform, the platform holds the funds while the transaction is in progress, and the platform releases to the seller on confirmation. Escrow is what gives the marketplace authority over disputes, because the marketplace is holding the money when the dispute happens.
This means a ledger, not a balance column. Every movement — buyer charged, funds held, platform fee taken, seller paid out, refund issued — is an append-only ledger entry. You never edit a balance; you derive it from entries. This is what lets you answer, at any instant, exactly where every dollar is and why. A marketplace that can't produce that answer can't survive an audit, a chargeback investigation, or a seller who insists they're owed money.
Use a processor built for splitting money — and don't let it own your ledger. Stripe Connect and its peers handle the hard regulatory parts of paying out to thousands of sellers, including KYC and the legal apparatus of moving money to third parties. Use one. But your ledger is your source of truth for what's owed; the processor is the source of truth for what physically moved. The processor executes payouts; your ledger decides them. Hand that decision to the processor and you've outsourced your own books.
The seams that leak money here: a refund that releases escrow and charges back, a payout that fires twice on a retry, a platform fee computed after a partial refund. Each is an idempotency-and-state-machine problem. Money operations must be idempotent and gated on transaction state — never fired from an event handler that can run twice.
Trust and safety: the product nobody sees until it's missing
Two strangers transact, and nothing in the listing tells either one whether the other is real, competent, or a scammer. Trust is the actual product of a marketplace; the listings are just inventory. And trust is a system, not a star rating bolted on at the end.
Reputation must resist gaming, or it's noise. A naive average rating gets farmed — sellers solicit fake reviews, buyers extort with the threat of a bad one. Reputation that holds ties reviews to completed, paid transactions in your ledger (no transaction, no review), weights recency, and surfaces the distribution, not just the mean. The signal has to be expensive to fake, which means anchoring it to real money having moved.
Identity verification scales with stakes. A $5 transaction and a $5,000 transaction warrant different verification. Design verification as tiers a participant can climb — email, phone, government ID, payout KYC — gated by what they're trying to do. Verify everyone to the maximum and you kill signup; verify no one and you've built a fraud marketplace.
Disputes need a defined process with the money still in escrow. This is why escrow and trust are the same system. When a buyer claims non-delivery, the transaction enters a disputed state, escrow stays held, and a resolution path — evidence from both sides, a decision, a release-or-refund — plays out before money moves. A marketplace that pays the seller before the dispute window closes has no leverage left to resolve anything.
Matching: connecting the right supply to the right demand
Matching is where a marketplace earns its existence — if buyers could find the perfect seller trivially, they wouldn't need you. But matching is also where founders over-build early, designing a sophisticated engine for a marketplace with eleven sellers.
Match the sophistication to the stage. Early on, matching is search and filter done well — fast, relevant, with the inventory you have. The discipline is making search honest about thin inventory rather than showing empty results that signal a dead marketplace. As liquidity grows, matching becomes ranking — relevance, reputation, availability, price, proximity — and eventually, for marketplaces where both sides have constraints (think shifts, rides, rentals), a genuine allocation problem of assigning limited supply to competing demand without starving either side.
Build the matching for the liquidity you have, not the liquidity in the deck. A ranking engine tuned for scale produces worse results than honest search when there are forty listings.
The failure modes that kill marketplaces
These are the ones that end the business, not just the sprint:
- Cold start — the empty marketplace. Buyers won't come without sellers; sellers won't list without buyers. This is a go-to-market problem with an architecture consequence: the system must be usable and honest at low liquidity. Don't show "0 results"; show the closest available and make sparse inventory feel like a real, if early, market. Architect for the awkward early phase, because every marketplace lives there first.
- Disintermediation — the deal that leaves your platform. Once two parties meet, they have every incentive to transact off-platform and skip your fee. You can't prevent it entirely, but the platform must hold something they'd lose by leaving: escrow protection, dispute resolution, reputation that doesn't travel. If the only thing you provide is introductions, you'll be disintermediated to death.
- Fraud at the seams. Stolen cards on the buy side, fake listings on the supply side, collusion between fake accounts to launder money or farm reputation. Fraud lives in the gaps between systems, which is why payments, identity, and reputation can't be three disconnected features — they're one trust system.
- Liquidity imbalance. Too much supply and sellers leave unpaid; too much demand and buyers leave unserved. The matching and incentive systems have to actively defend balance, which means instrumenting both sides and noticing the tilt before participants do.
What fixed looks like
Participants are modeled as identities with roles, so the same account buys and sells without fighting the schema. Transactions are explicit state machines, so every money decision is gated on a state that can't be set to anything by anyone.
Money flows through escrow against an append-only ledger, so the platform holds funds when disputes happen and can prove where every dollar sits. Payouts are idempotent and state-gated, so a retry never pays twice. The processor moves money; your ledger decides it.
Reputation anchors to real, paid transactions and resists farming. Verification scales with stakes. Disputes resolve with the money still held, so the platform has leverage exactly when it needs it. And matching fits the liquidity you actually have, staying honest while the market fills in.
./marketplace --money=escrow+ledger --trust=earned --match=to-liquidity
This is for you if
You're building a real two-sided marketplace where strangers exchange money — funded, past the toy stage, with enough transaction volume that disputes, chargebacks, and fraud are about to be your daily reality. This is a $50k+ engagement: the participant and transaction models, escrow with a real ledger, the trust system, and matching sized to your liquidity. For marketplaces moving serious money across many sellers — payouts at scale, KYC tiers, dispute operations, fraud defense across the seams — it's the $100k+ build, where payments and trust become the core of the platform and getting the money architecture right is existential.
It's the right time if money currently moves buyer-to-seller directly, if you track balances in a column instead of a ledger, or if your schema has separate buyer and seller tables you're already fighting.
This is not for you if you're validating that anyone wants the marketplace at all — pre-liquidity, hand-matching the first transactions, money moving by other means while you prove demand. Don't build escrow and reputation infrastructure before you have a market to protect. Architect this the moment real money and real strangers arrive, because both are coming faster than the deck suggests.
< transmit >