Every marketplace founder arrives with the same sentence: "we hold the money until the job is done." It is the right instinct, and who ends up holding it is a decision with a legal shape as well as a technical one. This piece is about the other half of it: what that promise costs to build, and when to skip it.

What you are actually buying

Escrow is not a payment integration. Payment integrations are a week. Escrow is a set of promises your software has to keep when things go wrong, and each promise is code that has to exist before launch:

  • A deposit that is held, not spent. The money arrives, and it belongs to neither side until a condition is met. Your provider has to support this — not every one does in every country — and your accountant has to agree with the arrangement.
  • A release with a reason. Funds move when the buyer accepts, when a deadline passes, when an administrator decides a dispute. Three different triggers, three different audit trails.
  • A refund path that survives partial delivery. The seller did half the work. Nobody planned for that, and yet it is the most common outcome of a bad order.
  • A dispute flow with deadlines. Someone has to be able to open one, attach evidence, and get an answer inside a stated window. Without deadlines it is not a flow, it is a queue.
  • A payout that can fail. Bank details wrong, account frozen, provider down. The money has to end up somewhere sane, and the seller has to be told what happened.

In the marketplace we run that surface is eighteen endpoints on its own, and the tests that guard them are the ones we run before every push — not because they break often, but because when they do break, they break quietly and in the direction of money.

Where the time goes

A catalogue is a week. Accounts are a week. The money path is the rest of it, and the reason is not the happy case — it is that every state has to be correct after a crash, a double tap, a webhook that arrives twice, and a user who closes the app mid-payment.

That is why our marketplace build is twelve weeks and $24,000 rather than the eight weeks and $19,000 of an app with one journey. The extra four weeks are almost entirely the states nobody demos.

When you should not build escrow

We say this regularly, and it costs us the bigger project every time:

Your two sides already trust each other. A supplier network where everyone has contracts and invoices does not need funds held. It needs a portal, and a portal is cheaper.

Your transaction is small and instant. If nothing is delivered later, there is nothing to hold money against. Take payment, take a fee, move on.

You have no supply yet. Escrow protects a transaction that is not happening. Get twenty sellers who will actually list, on a spreadsheet if necessary, and then build.

Your regulator says no. In several countries holding client funds without a licence is not a design decision, it is an offence. Find this out before the build, not during.

The version in between

There is a middle path worth knowing about: the provider holds the funds, you only trigger the release. You get the guarantee your users care about without ever touching the money yourself. It is usually a smaller legal problem and roughly the same engineering, and it is where we start most conversations.

The thing to take from this: escrow is a business decision with an engineering price tag attached, not the other way round. Decide it with your accountant in the room, and get the number for both options before you pick one. If you want that number for your shape of marketplace, describe it to us — the estimate comes with the assumptions written down.