← All solutionsTwo-sided marketplace app · Creator economy

Marketplaces where the money sits in the middle

A marketplace with two sides, a payment held between them, and an AI studio that bills by the generation. The hard part is never the catalogue — it is deciding, in code, the exact moment money and files change hands.

The problem behind every two-sided marketplace app

Two-sided marketplaces look like a catalogue with a checkout bolted on. They are not. The catalogue is a week of work. What takes the other months is the question every such product has to answer: who is holding the money right now, and what has to be true before it moves. Get that wrong and you do not get a bug report. You get a buyer who paid and received nothing, or a seller who delivered and was not paid — and either one costs you the marketplace, because the whole product is a promise that neither can happen. The second question, asked less often and just as expensive, is why either side should keep using you once they have met. Two people introduced by your platform can agree in a chat window and pay each other directly, and every rule that stops them is a decision about how much friction the product can carry before it stops being pleasant. That decision is not a policy page. It ends up written into the transport layer, the order states and the moderation tools, which is why it has to be made early.

What is hard inside a two-sided marketplace app

The order is a state machine, and money is one of the states

An order moves through pending, awaiting payment, in progress, review, and then done, revision or dispute. Each edge has a rule about funds and file access, and every edge needs a negative case: what happens if the buyer pays twice, if the seller vanishes at review, if either account is banned mid-deal. We wrote a dedicated test suite for that last one, because a ban that quietly strands a paid order is worse than no ban at all.

The payment provider is the source of truth, not the phone

The buyer pays in a provider web view and the app may be backgrounded, killed or offline before the payment finishes. So the order does not start when the screen says success — it starts when the provider posts a webhook to the backend. That means treating repeats and out-of-order deliveries as normal traffic rather than as errors, and it means the client is never allowed to assert that money arrived.

Delivered work has to be worthless until it is paid for

The seller uploads a video and the server transcodes a watermarked copy with FFmpeg. The buyer reviews only that copy. The clean original is released at the moment the work is accepted, and the watermarked version stays in the order archive as evidence if a dispute is opened later. File access is therefore not a permission on a user — it is a function of the order state.

An AI studio where every click spends real money

Generation is metered in credits: packages are bought, generations are charged, and a failure refunds. The balance is debited inside one database transaction with the balance condition in the update itself, so two taps cannot spend the same credit twice, and every movement is written to a ledger rather than adjusting a number in place. Generation runs asynchronously through queued, processing and then done or failed; on failure the credits go back with their own refund entry, because charging for something that did not happen is the fastest way to lose a paying user.

The AI provider is behind an interface on purpose

Image, video and video-compilation generation sit behind one provider interface, injected by token, with a mock alongside the real Vertex AI implementation. That is not architectural neatness — it is what lets the whole credit and refund economy be tested end to end on every commit without spending a rouble on inference. There is also a free discussion mode with an admin-editable system prompt, so the paid path is the one that produces media, not the one that answers questions.

The chat is where a marketplace leaks

Before a deposit exists, the websocket refuses a message containing a phone number, refuses one containing an email address, and refuses attachments outright. Each of those three is a test rather than a hope. After payment the same channel opens up, because by then the deal belongs to the platform and the files have somewhere safe to live. Deciding exactly when it opens is a product argument that ends up as rules in the transport layer, and getting it wrong in either direction is expensive: too strict and people cannot work, too loose and your best pairs leave together.

A ban is a decision about the orders already in flight

Banning a seller is simple until you ask what happens to the buyer who paid them an hour ago. Here it moves the active order into dispute and opens arbitration, and the seller's work disappears from the public feed at the same moment. Unbanning restores the portfolio and deliberately does not resolve the dispute — that stays with a human, because "the account is back" and "the deal was fine" are different statements. Those four sentences are four tests, and they were settled before the ban button was built.

Money cannot sit waiting for somebody to remember it

A payment that reaches hold and then meets nobody clicking anything is the state a marketplace quietly dies in. A scheduled job releases deposits held or awaiting release past their deadline, so an inattentive buyer cannot strand a seller's payout indefinitely. Around it sit the rules nobody demos: one order gets one deposit, a brand cannot fund somebody else's order, a seller cannot delete another seller's work. Each is a negative test, and each is a support ticket that never arrives.

Most of the work is the paths nobody demos

The build ended with 173 end-to-end tests across 24 suites, and their names are the honest map of where the difficulty was: deposits and their card fallback, the deposit cron, wallets, order submission and status, watermarking, ban effects, chat limits, and three separate suites of nothing but negative cases. The happy path was never the risk.

How we went at it

The order state machine was written down before any screen was, because every later argument — when to charge, when to release the file, what a dispute may reach back to — turned out to be an argument about that diagram.

Money and media were then treated as the same kind of problem: something irreversible that must only happen once. Credits are debited with the balance condition inside the update statement, so concurrency cannot double-spend them. Payments start the work only when the provider says so. Files are unlocked by order state rather than by user role.

Everything expensive sits behind an interface with a mock behind it, which is why the paid AI paths are covered by the same test run as everything else.

The awkward social rules were decided at the same time as the technical ones, rather than added after somebody complained. What a chat may carry before money exists, what a ban does to a deal already in progress, what an unban deliberately does not undo: each was written down as a sentence, then as a test, then as code. They read like policy and behave like architecture, and retrofitting them into a running marketplace means changing the meaning of records that already exist.

None of this is visible in a demo. It is, however, most of what separates a marketplace people trust with a payment from a catalogue with a checkout attached.

4 months

from kickoff to a working product

173

end-to-end tests, 24 suites

data models behind it

NestJS 11Prisma 7PostgreSQLFlutterReact 19Socket.IOFFmpegVertex AI

How it was built

The work behind this one, and what it costs

A case is easier to trust than a service page, and harder to buy from. These are the services this product was actually made of — each with a price and a scope on its own page.

from $24,000

Starting point

twelve weeks to a first release

First working version

That buys the three products a marketplace is: the app both sides use, the money path between them, and the back office that settles it. The app half on its own is $19,000 for eight weeks. Either way it starts with one journey working end to end — sign-in, an order, a payment held between two sides. The product below took four months, because escrow, arbitration, watermarking and a metered AI studio are each a phase of their own. Which of them you need in the first release is the conversation, and it is a cheaper conversation before anything is built.

Questions people ask about two-sided marketplace apps

The five that come up on nearly every first call about this kind of product.

The buyer pays into a hold rather than to the seller. The money is released when the work is accepted, refunded if it is not, and frozen if either side opens a dispute. In practice the hard part is not the holding, it is deciding every transition in advance: what happens if the buyer pays twice, if the seller disappears at review, if an account is banned mid-deal. Each of those is a rule about funds, and each one needs its own test.

Before a payment exists, our chat refuses messages containing a phone number or an email address and blocks attachments outright — three rules enforced at the websocket, not a warning in the terms. After payment the channel opens, because by then the deal is on the platform and the files have somewhere safe to live. It is not airtight, nothing is, but it moves leakage from the default to the exception.

The whole build — app, money path and back office — starts at $24,000 for twelve weeks; the app half on its own is $19,000 for eight. A marketplace with money genuinely moving through it — deposits, payouts, refunds, arbitration — is a four-month build in our experience, and the price follows the scope you pick rather than an hourly rate. We quote the shape before we start, and the parts we deliberately leave for phase two are written down.

Four months from kickoff to the product in the demo above, with the first usable release well before that. The catalogue is a week. The months go on the order state machine, the payment provider integration, file access tied to order state, and the negative paths nobody demos — which is also the order we build them in.

In every marketplace we have built the funds sit with a licensed payment provider and never in our client's own account, which is what keeps the licence question with the provider. The rules differ by country and by how long you hold the money, so confirm your model with the provider and a local lawyer before you plan around it — we will build to whichever model you land on.

Deeper on this

The parts of a marketplace that only break after launch
The demo always works. What fails in month two is the paid order whose seller was banned, the deposit that half-arrived, and the dispute about a file nobody kept. A list worth reading before you sign anything.
Adding AI to your product without handing your margin to the model
Generation costs money every time someone taps the button. Here is the metering, refund and abuse question to settle before you ship an AI feature, and what it looks like when it is done properly.
Who holds the money, and why that decision shapes your whole marketplace
Before the catalogue, before the app, one question decides your build, your legal shape and your support load: at what moment does the buyer stop owning the money and the seller start.
Commission, subscription or listing fee: picking how your marketplace charges
This is a business decision that quietly rewrites your software. Pick it before the build, because each answer needs a different thing to exist on day one.

Next caseOperations platforms where every order is one of oneMade-to-order production has no catalogue and no reorder button. Every item is built for one person from measurements a computer takes off a scan, and the system has to hold that thread from the first appointment through manufacturing, delivery, and the remake eighteen months later.

Tell us what you are building

A person reads it and sends an estimate within 12 hours: a price range, what the first version contains, and what moves the price.