Marketplace development cost: from a demand test to a full platform

Why a marketplace costs more than a store

An online store has one seller — you — and many buyers. A marketplace has many of both, and each side needs its own product:

• The buyer side: search, listings, booking or ordering, payment, order tracking, reviews.
• The supply side: onboarding and verification, profiles and listings, availability or stock, order handling, payouts, ratings.
• The rules between them: who pays whom and when, commission, cancellations and refunds, disputes, moderation, a log nobody can rewrite.
• The operator side: an admin team that approves sellers, moderates listings, resolves disputes and watches the numbers.

Each of these is a set of modules. That is why “a marketplace like Airbnb, but for X” cannot be priced without more detail: the phrase hides four products.

The operator side is easy to leave out of a quote, because users never see it. Yet the admin decides how many people you will need every day. If approving a seller, issuing a refund or handling a complaint is only possible through a developer, each of those actions ends up costing more than the module that would have handled it.

Typical ranges in 2026

An orientation for quotes from studios in Ukraine and Eastern Europe, not a price list; your scope decides where you land, and the estimate prices it module by module:

On the MVP scale from how much an MVP costs, a marketplace MVP sits at the top of the multi-role band: it has two or three roles like any multi-role product, plus payments held until completion and payouts to sellers. The general logic from that article applies too: fewer roles, fewer integrations and a manual back office all pull the number down.

The modules that drive the price

Payments: the module that is easy to underestimate

Taking money from one person and paying it to another is where marketplaces differ most from stores. The platform has to:

• take the buyer’s payment and hold it until the order is completed or confirmed;
• deduct the commission and pay the rest to the seller;
• handle cancellations, partial refunds and chargebacks;
• know who its sellers are, because payment providers and the law will ask.

There are legal questions too. Holding other people’s money can require a licence in some jurisdictions, so the safer route is a payment provider’s marketplace product: the provider, not the platform, holds and moves the funds. Which provider fits depends on your countries and business model; Stripe Connect is one option where Stripe operates, and in Ukraine the set of options is different. Talk to the provider and a lawyer before you design the flow, not after.

For an MVP, the cheapest honest version is usually this: card payment, money held by the provider, payout released by your admin once the order is complete. Automated payouts and detailed refund rules can wait until volume justifies them.

Step by step, that lean flow looks like this:

1. The buyer pays by card; the provider holds the money and the order becomes “paid”.
2. The seller accepts the order, or declines it and the buyer gets a full refund.
3. The job is done; the buyer confirms, or the order confirms itself after a set number of days without a complaint.
4. An administrator releases the payout: the seller’s share goes out, the commission stays.
5. If the buyer opens a dispute, the payout is frozen until an administrator decides on a full refund, a partial refund or a release.

Every step is a status, a notification to the right side and a line in the accounting report. That is why payments take a large share of a marketplace MVP budget even in their simplest honest form.

A related question is when money becomes the platform’s revenue. If the commission is deducted at payout, your accountant needs to see every deal separately: the buyer’s payment, the commission, the payout and any refund. Put a report for accounting into the first release; it costs less than reconstructing those numbers by hand later.

When trust is the product

Some marketplaces sell trust between strangers more than they sell listings. A-Search, an automotive inspection marketplace from our portfolio, is one example: a buyer pays for an independent check of a car they cannot see in person. In products like this, the weight of the budget is not in the listing pages but in what makes a stranger’s work believable: a fixed checklist with evidence for every point, payment held until the result arrives, a path for disputes, a log nobody can rewrite, and one order lifecycle that every role sees from its own side. If trust between strangers is your product, these modules are not optional, and a quote without them is a quote for a different product.

One marketplace, two first releases

Take a hypothetical marketplace for home cleaning in one city.

Release A, lean. A web app. Cleaners are onboarded by your team after an interview. Customers pick a service and a time slot and pay by card; the money is held until the job is marked done, and an administrator releases the payout. Customers rate the cleaner after a completed job. An admin panel runs the rest.

Release B, everything. Mobile apps for both sides, self-registration for cleaners with document checks, instant automated payouts, paid plans for cleaners, in-app chat, a dispute process with arbitration, and three cities at launch.

Release A answers the only question that matters at the start — will people book, pay and come back — for a fraction of what release B costs. Every item in B is a reasonable later decision, made with data from A behind it. On the table above, release A is a marketplace MVP at the lower end of its band; release B is a growth platform from day one, with the budget and the five to nine months that come with it.

The cheapest marketplace is a narrow one

Marketplace budgets are easily blown on breadth: every category, every city, every role at once. The cheaper and usually wiser path:

• One niche, one city or one deal type. Prove that transactions happen and repeat.
• Supply first. Onboard sellers by hand, import catalogues or partner feeds, so buyers don’t land in an empty marketplace. More in how to launch a two-sided marketplace.
• Operations run by people. Matching, moderation and payouts from the admin; automate them later.
• Web before mobile. A responsive web app is enough for the first transactions; a mobile app pays off when people come back often.
• Reviews tied to real orders only, from day one. Retrofitting trust is harder than building it in.

What belongs in version one is covered step by step in marketplace MVP: the features you need on day one.

Questions that change the estimate

Before you ask for a quote, write down the answers to these. Each one can move the price by a whole module:

• Does money pass through the platform, or do buyers pay sellers directly?
• Who sets the price: the seller, the platform or a negotiation?
• Is it a one-off purchase, a booking in time, or a service with stages?
• How do you check a seller before they go live?
• What happens when a buyer says the order was not delivered as promised?
• Where will the first hundred sellers come from?
• Which side uses a phone more than a laptop?

The answers don’t have to be final. “We don’t know yet” is an answer too; it just means the developer will price in the risk.

Running costs to expect

• Payment fees on every transaction, which can be higher for marketplace products than for simple card payments — check the provider’s tariff.
• Identity and document checks, if you verify sellers through a service.
• Moderation and support time — people, not code, and growing with volume.
• Hosting, maps, SMS and email, plus storage for photos and documents.
• Development of the next category, city or role, because a growing marketplace keeps changing shape.

Ask the developer to list the technical costs separately, and estimate the people costs yourself: no quote will show them.

How we price a marketplace

Describe your marketplace in your own words — text, a link, a file or a voice message — and the estimate splits it into modules — catalogue, orders, payments, cabinets, admin — with hours, a timeline and a price in about 15 seconds. The estimate is free and non-binding. At the team review we help you cut the first release down to what the first transactions need, and then the contract fixes the price. A marketplace moves other people’s money, so at EVA-X we recommend AI + DEV for the first release and DEV once volume grows; AI Build fits a clickable prototype for testing demand with a handful of users. More on what we build: marketplace development.