Cube of spheres, the studio mark

12 years building custom software

Build a marketplace where the money survives the argument

Two sides that need each other, a payment that has to wait until the work is accepted, and a disagreement that has to end somewhere. Not a shop and not a storefront on someone else’s platform — a marketplace of your own. We have built one and you can open it right now.

See our work
Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//Marketplace Development//
Sound familiar

The matching works. The money is where it falls apart

  • “People find each other on our platform and then take the deal to a private chat.”

    Disintermediation is not a loyalty problem, it is a value problem. Both sides leave when staying inside costs them something and buys them nothing. Escrow, dispute cover and a record of what was agreed are what make staying worth it.

  • “We hold the money in a spreadsheet and pay out by hand every Friday.”

    It works up to about fifty transactions a month, and then it becomes someone’s full-time job — a job where a single wrong row is a customer who does not come back and a refund out of your own pocket.

  • “When two users disagree, it lands in our inbox and we improvise.”

    Every improvised decision is a precedent you will be held to, and none of them are written down. A dispute flow is not bureaucracy: it is the difference between a rule and a mood.

  • “We tried a ready-made marketplace platform and outgrew it in the first quarter.”

    Boxed platforms assume commission, one currency, one payout schedule and one definition of "delivered". The moment your model differs — a deposit, a milestone, a partial refund — you are writing workarounds around software you also pay for.

The first version

Both sides, one live payment path, in twelve weeks

from $24,000
Fixed against a scope agreed before we start. Dearer than a single-audience product for one reason: a marketplace is two journeys that meet on money, and the meeting is the hard part.
Twelve weeks
From first call to a platform running real transactions between real users.

What you get

  • Two roles with their own journeys: the side that pays and the side that gets paid
  • Payment held from order to acceptance, with the release rules written down
  • Commission taken automatically, at a rate you can change without us
  • A dispute flow with states, deadlines and an outcome — not an inbox
  • Payouts, including the part where a payout fails and has to be retried
  • An admin panel where a human can see any deal and intervene in it
  • End-to-end tests over the money paths, in your repository

What is not included

  • A payment licence, or acting as the money transmitter on your behalf
  • KYC and anti-fraud beyond the provider’s own checks
  • Native mobile apps for both sides — that is the mobile service, quoted separately
  • Marketing, seeding the supply side, or getting your first hundred sellers
  • Multi-currency settlement and international payouts in version one
173
end-to-end tests green on our own marketplace
21
data models, six of them about money
4 months
from first call to a working product
What ends up built

The parts of a marketplace, and which of them go in first

Marketplace development goes wrong in a predictable way: the catalogue and the profiles get built first because they are visible, and the money is left for later because it is hard. Then launch arrives and the hard part has not been designed at all. We do it in the other order, and this is the split we usually propose.

Which journeys go into which stage of the work
JourneyFirst twelve weeksPhase twoNot us
Two accounts, two journeys, one identityA buyer and a seller are not the same person with a flag — different onboarding, different empty states, different first minute.Covered · First twelve weeksNot covered · Phase twoNot covered · Not us
Order with money held until acceptanceThe centre of the product. Held, released, refunded, partially refunded, and every one of those states reachable in tests.Covered · First twelve weeksNot covered · Phase twoNot covered · Not us
Commission and the ledger under itEvery movement recorded as a transaction. If you cannot answer "where is this money right now" from the database, you do not have a marketplace, you have a website.Covered · First twelve weeksNot covered · Phase twoNot covered · Not us
Disputes with deadlines and an outcomeOpened, evidenced, decided, and the decision moves the money. Without this the support inbox becomes the product.Covered · First twelve weeksNot covered · Phase twoNot covered · Not us
Payouts, including the failed onesA payout that bounces is not an edge case, it is a Tuesday. It needs a state, a retry and someone to notice.Covered · First twelve weeksNot covered · Phase twoNot covered · Not us
Admin panel for the humans on your sideFind any deal, see its history, refund it, ban a user. Built for your operations person, not for us.Covered · First twelve weeksNot covered · Phase twoNot covered · Not us
Ratings, reviews and reputationImportant, and not urgent: reputation matters when there is repeat business, and in week twelve there is none yet.Not covered · First twelve weeksCovered · Phase twoNot covered · Not us
Native apps for both sidesUsually a phase-two decision made with real numbers about where your users actually are.Not covered · First twelve weeksCovered · Phase twoNot covered · Not us
Becoming the payment provider yourselfLicensing, compliance and holding client funds are a different business with a different regulator. We integrate providers; we do not replace them.Not covered · First twelve weeksNot covered · Phase twoCovered · Not us
includednot in this stage

The exact split comes out of the first week, with you in the room. What does not move is the order: money first, decoration after.

Escrow is a state machine, not a feature

The word "escrow" hides how much of it is bookkeeping. Money arrives and is held. Work is submitted. The buyer accepts, or says nothing until a deadline passes, or rejects. A dispute opens and freezes the clock. A partial refund splits the held amount three ways: back to the buyer, on to the seller, and the commission you already counted as revenue. Each of those is a state, each transition has rules about who may trigger it, and every one of them has to be reachable from a test — because the first time you discover a missing transition should not be with someone else’s money inside it.

Who holds the money, and what that means legally

The dispute flow is the product, not the support process

Founders usually plan to handle disputes personally "at first". That works for the first dozen and then quietly becomes the thing you do all day, with no record of why you decided what you decided. A dispute needs states, a deadline on each side, a place to attach evidence, and an outcome that moves money by itself. Ours has all of that, and the reason is not tidiness: it is that a written rule can be shown to an angry user, and a mood cannot.

Two sides means two empty screens, and one of them is fatal

A marketplace launches empty on both sides, and the two emptinesses are not equal. Buyers seeing no sellers leave and might come back. Sellers seeing no buyers leave and tell other sellers. Which side you seed first is a business decision, but the product has to support it: invitation flows, seeded categories, a way for the first sellers to look established before they are. We build for the side you choose to seed, and we will ask you which one in week one.

Money movements need to be answerable in one query

The question that comes eventually is always the same: where is this money right now. If answering it means reading application logs, reconciling with the provider dashboard and asking a developer, the marketplace is already in trouble. Every movement — hold, release, commission, refund, payout, reversal — is a row with an amount, a direction and a reason. Our own marketplace carries 21 data models and six of them exist purely so that question has a one-line answer.

How we design data models that survive

What a ready-made platform costs you later

Sharetribe, Arcadier and their relatives are genuinely good until your model differs from the assumptions in the box: a deposit before work starts, milestone payments, a commission that changes by category, a payout schedule that is not immediate. At that point the choice is to change your business to match the software or to leave. If your commercial model is ordinary, buy the box — we will tell you so on the call. If the part that differs is the part that earns your money, custom pays for itself in the first year of not working around it.

Why a marketplace is three products, not one

And what we do not do

  • We do not hold your users’ money — the payment provider does, and you contract with them directly
  • We do not write your terms of service; a lawyer in your jurisdiction does that, and it matters
  • We do not promise a marketplace works as a business. We build the machinery; supply and demand are yours
  • We will not ship a launch without tests over the money paths, whatever the deadline
How it runs

Twelve weeks, and something real at the end of each one

The order is deliberate. The money path exists in week four, when there is still time to be wrong about it; the parts everyone else builds first arrive after, because they are the parts that never surprise anyone.

  1. Week 1

    The two sides, and where they meet

    Who pays, who gets paid, what "delivered" means for you, and what happens when the two disagree about it. We come out of this with the state machine drawn and the commission model written as arithmetic rather than a sentence.

    You seeA diagram of the money path and a list of every state it can be in.

  2. Weeks 2–3

    Accounts, roles and the skeleton

    Both roles, both onboardings, the data models under them. Deployed to a real address at the end of week three — from here on you are looking at software, not slides.

    You seeYou can register as both sides and see the empty product they will see.

  3. Weeks 4–6

    Money, held and released

    The payment provider connected, the hold in place, release on acceptance, the deadline that releases it automatically, commission taken, ledger written. Tests over every path, including the ugly ones.

    You seeA real payment moves between two test accounts and lands correctly.

  4. Weeks 7–8

    Disputes and refunds

    The part that gets postponed everywhere else. Opening, evidence, deadlines, the decision, and the partial refund that splits a held amount three ways without losing a cent to rounding.

    You seeYou can run a full argument between two accounts and see the money end up right.

  5. Weeks 9–10

    Payouts and the admin panel

    Getting money out, and the human tools around it: find a deal, read its history, refund it, ban a user, fix what the automation could not. Built for your operations person on their worst day.

    You seeYour own team can run a transaction from both sides and intervene in it.

  6. Weeks 11–12

    Hardening and handover

    Your people try to break it while we watch. Then the pipeline, the runbook and the accounts move to your side, and one of your developers deploys the platform once, with us watching instead.

    You seeEverything in your accounts, deployed by your developer, tests green on every push.

Runs with what you already use
  • Stripe Connect
  • PayPal
  • YooKassa
  • NestJS
  • PostgreSQL
  • Flutter
  • GitHub Actions
What you keep

Three things from our own marketplace, not from a brochure

Everything below is taken out of the repository behind the case study you can open on this site. The same three things are what you keep when we build yours.

Terminal output of the end-to-end run: 24 suites passed, 173 tests passed, 2 skipped

A suite that guards the money paths

Twenty-four suites, one hundred and seventy-five tests, two of them skipped and marked as such. They cover the declined card, the dispute opened after acceptance, the deposit refunded twice and the payout that bounces. The screenshot is the run itself, warnings included — we did not tidy it up for the page.

jest over test/*.e2e-spec.ts in ugc.backend, 21 August 2026

The Deposit model from schema.prisma: amount as a decimal, refund deadline, status enum

A data model where money has a place to be

Twenty-one models, six of them about money. Here is the one that holds a payment between two people: the amount as a fixed-precision decimal rather than a float, the deadline after which a refund is no longer possible, and a status that is an enumeration instead of a boolean — because a deposit is never simply paid or unpaid.

prisma/schema.prisma in ugc.backend

Eighteen REST endpoints covering deposits, disputes and payouts

An API your next developer can read

Seventy-two endpoints, documented as OpenAPI rather than described in a wiki someone stopped updating — eighteen of them for deposits, disputes and payouts alone. That specification is what makes a handover a handover instead of a hostage situation.

the OpenAPI specification of ugc.backend, filtered to the money paths

Be honest with yourself

A marketplace is worth building for some businesses and ruinous for others

Build this if

  • Two sides already transact — on WhatsApp, in a spreadsheet, through you personally — and it is straining
  • You take a cut, or intend to, and the cut is the business model rather than an afterthought
  • The money has to wait somewhere between payment and delivery, and today that somewhere is your own account
  • Disputes happen often enough that you can describe a typical one from memory
  • You know which side you will seed first and roughly how
  • A boxed platform has already been tried, or ruled out for a reason you can name

Do not build this if

  • Neither side exists yet — software will not create supply, and a marketplace with one side is a very expensive landing page
  • You need a payment licence and do not have one; that comes first and it is not a development question
  • A commission model is not decided — the number can change later, but the shape cannot
  • What you actually need is a shop: one seller, many buyers, no escrow, no disputes. Shopify does that better and cheaper
  • The plan is to launch in six weeks. The money path alone takes longer than that to build honestly

If that reads like a no, say so on the call. Twice this year the honest answer was "start on WhatsApp and come back at fifty deals a month" — it cost us the project and saved the client a year.

Questions we get about building a marketplace

Short answers. The long ones happen on the call.

A first version with both sides and a live payment path starts at $24,000 for twelve weeks, fixed against a scope we agree before starting. A full platform runs further — our own took four months and kept growing after. Marketplace app development costs more than a single-audience product for one reason worth understanding: you are building two journeys and the machinery where they meet, and that machinery is where the money lives.

Often, and we will say so. Sharetribe and its relatives are cheaper than anything custom until your model stops matching their assumptions — a deposit before work starts, milestones, a commission that varies by category, a delayed payout. The question is not whether your business is special. It is whether the part that differs is the part that earns your money. If it is not, buy the box and spend the difference on demand.

The payment provider does, and you contract with them directly — Stripe Connect, PayPal or YooKassa depending on your countries. We build the logic that tells the provider when to hold, when to release and how to split, and the ledger that lets you answer where any amount is right now. We do not touch the funds, and any studio offering to hold them for you is describing a licensing problem rather than a feature.

Not with rules, because rules are unenforceable once two people have each other’s phone numbers. With value: money held until the work is accepted protects the buyer, a dispute process protects both, and a public record of completed deals is worth something to the seller. Leaving has to cost more than staying. Everything else — contact masking, penalties — is a speed bump on the way out.

Week six on our schedule. That is deliberate: the money path is built before the parts that everyone finds easier to imagine, because it is the only part where being wrong is expensive. By week six you can move a real payment between two accounts and watch where it lands.

Usually not in the first version, and the honest test is where the paying side already spends its time. A responsive web product covers both roles on a phone well enough to learn what your users actually do. When the answer is genuinely native, that is a separate eight weeks and we quote it separately rather than bundling it into a number you cannot examine.

It gets a state, a retry and a person who is told. A bounced payout is not an edge case — bank details go stale, accounts get frozen, providers have bad days. The failure mode that ruins a marketplace is not the failed payout; it is a failed payout nobody noticed until the seller wrote an angry message a week later.

Yes, and without asking anyone. The case study on this site has a demo you can open and use on test data — both roles, the ordering flow and the AI studio that bills by the generation. The numbers on this page come from that product’s repository, and the test run in the artefacts section is from the day this page was written.

You do, from the first commit. The repository is in your organisation, the infrastructure in your accounts, the payment provider account in your name. Handover is a rehearsal we run in week eleven, not a folder we send in week twelve — the honest test of ownership is whether you could carry on without us, and that is easier to check than to promise.

Selected work

A marketplace we built and still run, and its nearest relative

Two products rather than a gallery, because we would rather show two whole than five in fragments. The first is this service finished; the second is the same discipline at a larger size. Both are open — you can use them on test data without registering.

Two-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.

This is the service on this page, finished: escrow between brands and creators, a dispute flow, an AI studio billed by the generation, and the 173 tests whose run you can see above.

4 months
from kickoff to a working product
173
end-to-end tests, 24 suites
21
data models behind it
Live demo insideRead the case
Creator feed in the marketplace app, with an order button
Made-to-order production platform · Medical manufacturing

Operations platforms where every order is one of one

Made-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.

Not a marketplace, but the same discipline applied to money and roles at a larger scale: 81 data models, 2,053 automated checks, and a shop floor that keeps working when the internet does not.

8 months
and still building — the largest system we run
13
flow families, from intake to remake
2,053
automated checks across its three repositories
Live demo insideRead the case
Order board in the operations platform, with production stages
Every solution we build

What a build like this costs, and how it gets tested

All articles →

Talk to us about marketplace development

Tell us what you are building

A person reads it and answers within one business day — with a range and the assumptions under it.