Every marketplace demo goes the same way. A buyer finds a seller, they agree, money moves, work is delivered, everyone smiles. It is a fair demonstration of the happy path, and the happy path is not where products fail.
What follows is a list of the things that actually go wrong, drawn from building one. If you are commissioning a marketplace, it is a useful list to read out loud to whoever is quoting you, and to notice which items produce a confident answer and which produce a pause.
An account is suspended while an order is live
Someone breaks your rules. You ban them. They have four paid orders in progress.
Now what? The buyers have paid. The work may be half done. The money is sitting somewhere. If nobody decided this in advance, the answer is whatever the code happens to do, which is usually nothing — the orders simply stop existing for one party and hang forever for the other.
This deserves an explicit policy and its own tests. Ours got a dedicated suite, because the failure is silent and the people it hurts are the ones who did nothing wrong. It is the same principle as deciding who holds the money in the first place: the rule has to exist before the situation does.
The payment half-arrived
Card payments fail in more interesting ways than "declined". The provider accepts it and the webhook never lands. The webhook lands twice. The webhook lands before your own database has finished writing the order it refers to. The user's card is charged and the provider's own status is still pending an hour later.
Each of these needs a defined behaviour, and at least one of them needs a scheduled job that goes back and reconciles what the provider thinks happened against what you think happened. If the quote you are reading has no line item resembling "payment reconciliation", the money paths have been costed as the happy path.
Two people want the deal off your platform
Your seller and your buyer have now met. Your fee is the only thing standing between them and doing the next job over email. This is not a rare edge case, it is the normal economics of every marketplace, and it is why platforms constrain what can be exchanged in chat before a deal is struck.
There is no perfect answer, and the aggressive versions annoy honest users. But you should have a deliberate position, because "we did not think about it" gradually becomes "we have no revenue".
A dispute about a file nobody kept
Three weeks after an order closed, a buyer says the delivered work was not what was agreed. Can you see what was delivered? If the file was replaced, or the seller deleted their account, or you only ever stored the final version, then the dispute is decided by whoever complains more persuasively.
Keeping an immutable copy of what was actually handed over, at the moment it was handed over, costs very little at build time. Reconstructing it afterwards costs a customer.
Notifications that arrive at the wrong time
The seller gets "your order was paid" while they are asleep. The buyer gets "your work is ready" four hours after it was ready, because a queue backed up. Someone gets a notification about an order that was cancelled thirty seconds earlier.
Notifications feel cosmetic and behave like infrastructure. On a marketplace they are how one side knows the other side acted, which makes them part of the transaction, not decoration on top of it.
The feature that is popular and losing you money
If your product has an AI feature, add one more to the list: a generation that fails after the user was charged for it. Metering, refunds and rate limits are their own conversation, and we have written that one down separately.
What this means for your quote
None of these are exotic. All of them are ordinary consequences of two strangers exchanging money and work through your software. But they are invisible in a feature list, which means they are easy to leave out of an estimate and expensive to add later.
When we finished the marketplace this list comes from, the end-to-end test suite had grown to 173 tests across 24 files. Their names are the honest record of where the work went: deposits and their card fallback, the reconciliation job, wallets, order submission, order status, watermarking, ban effects, chat limits — and three separate files containing nothing but negative cases.
The happy path was never the risk. It never is. That is equally true of systems that run a production floor, where the equivalent list is about remakes and lost measurements rather than deposits.
How to use this list
Read it to whoever is quoting you. Not as a trap — as a way of finding out which kind of studio you are talking to. Someone who has shipped a marketplace will recognise every item and have an opinion about half of them. Someone who has not will agree pleasantly with all of it, and then quote you for the demo.
The difference between those two quotes is not the price. It is which one still stands in month four.
We are the first kind, and we would rather show you than say so — the marketplace build behind this list is written up with the awkward parts left in. If yours is at the sketch stage, tell us about it and we will tell you which of these will bite you.