Short answer: a first release of a two-sided marketplace usually takes 20 to 55 person-weeks of work. At the $50 an hour typical of a Central or Eastern European or Turkish studio that is roughly $40,000 to $110,000; at US or UK agency rates of around $150 an hour it is about three times as much. A fully featured version with separate customer and provider apps, held payments, live location and a dispute workflow can pass 85 person-weeks. Most of the difference between those figures is scope you can choose not to build yet.
About these numbers. They are planning estimates built from typical effort and typical market rates. They are not survey results and not a BBR price list. The arithmetic is shown so you can redo it with your own scope and the rate you are actually quoted.
Why a marketplace is three products
The method is the same one used in our guide to MVP budgets: cost equals effort in person-weeks multiplied by a weekly rate, plus a margin for risk. A person-week is about 40 hours, so it costs $2,000 at $50 an hour and $6,000 at $150 an hour.
What changes for a marketplace is the effort side. You are building:
- A customer product: discovery, search, a booking or ordering flow, payment, order history, reviews.
- A provider product: onboarding, profile or listings, availability, accepting and fulfilling orders, earnings and payouts.
- An operator product: the admin panel where your team approves providers, fixes orders, issues refunds, resolves disputes and watches the numbers.
Every feature touches at least two of the three. A cancellation, for instance, needs a customer screen, a provider notification, a refund rule, a payout adjustment and an admin override. That multiplication, more than any single hard feature, is what makes marketplaces expensive.
Effort by building block
The figures assume an experienced team and a standard interface, and include the backend work each block needs.
| Building block | Typical effort | What makes it bigger |
|---|---|---|
| Accounts, roles and login for customers, providers and staff | 1.5–3 person-weeks | Social login, one person holding both roles |
| Provider onboarding, profiles and listing management | 2–4 person-weeks | Document checks, approval steps, many listing types |
| Search and filters | 2–4 person-weeks | Ranking rules, large catalogues, a dedicated search service |
| Location: geo search, maps, service areas | 1–3 person-weeks | Live tracking of a provider on the way |
| Booking or order flow: request, accept, status changes, cancellation | 3–7 person-weeks | Quotes and negotiation, recurring bookings, multi-item baskets |
| Availability and calendar | 1.5–3 person-weeks | Time zones, buffers, calendar sync |
| Payments with split payouts through a payment provider's marketplace product | 3–5 person-weeks | Several countries and currencies, tips, partial refunds, tax handling |
| Escrow-style hold and release of funds | +1–2 person-weeks | Milestone releases, rules that depend on dispute outcomes |
| Messaging between customer and provider | 2–4 person-weeks | Photos and files, moderation, masking of contact details |
| Reviews and ratings | 1–2 person-weeks | Two-way reviews, replies, abuse reporting |
| Notifications: email and push | 1–2 person-weeks | SMS, per-user preferences |
| Disputes, cancellations and refund tooling | 1–3 person-weeks | Evidence upload, staged resolution, automatic payout adjustments |
| Admin panel | 3–6 person-weeks | Finance reports, content moderation, staff permission levels |
| Backend foundation: API, database, hosting, monitoring | 2–4 person-weeks | Complex commission rules, third-party data |
| Mobile app shell and store release, per app | 1.5–2 person-weeks | Tablet layouts, several languages |
| Dedicated provider mobile app instead of a web portal | +4–6 person-weeks | Offline use, background location |
| Design: flows and screens for all roles | 3–8 person-weeks | Custom illustration, a full design system |
| Testing, deployment, project management | +25% on top | Every flow has to be tested from both sides, which is why this sits at the higher end of the usual 20–30% |
A note on payments
Payments are the block founders most often underestimate. Charging a card is simple. Charging a customer, keeping a commission, paying the remainder to a provider whose identity has been verified, and reversing all of that correctly when an order is cancelled is not. Payment companies sell products made for this, such as Stripe Connect, Adyen for Platforms and Mangopay. They handle seller identity checks, keep funds inside their own regulated system and pay out on a schedule you control, which is how most marketplaces achieve an escrow-style flow without holding money themselves.
Two practical points. First, check which countries your providers can be paid in before designing anything, because coverage varies by provider. Second, the integration effort above is mostly in the unhappy paths: failed payouts, refunds after payout, chargebacks and providers who never finish verification.
Three worked examples
1. Operator-assisted marketplace on the web
One city, one service category. Your team recruits providers and creates their listings. Customers browse, request a booking and pay by card on a responsive website. Providers receive requests by email and confirm through a link. Payouts and disputes are handled by hand.
Accounts 1.5, listings and search 2, booking flow 3, card checkout 1.5, email notifications 0.5, admin panel 2.5, backend 2, design 3. That totals 16 person-weeks; with 25% for testing, deployment and management it comes to 20 person-weeks: roughly $40,000 at $50 an hour and $120,000 at $150 an hour.
One caution: if customers pay you and you pay providers later by bank transfer, ask your payment provider and an accountant whether that is acceptable where you operate. If it is not, move split payouts into this release and add about three person-weeks.
2. Customer app with a provider web portal
A cross-platform customer app for iOS and Android, a web portal where providers manage listings, availability and orders, automated split payouts, messaging, reviews and geo search.
Accounts 2.5, provider onboarding and listings 3, search 3, location 1.5, booking flow 5, availability 2, split payouts 4, messaging 2.5, reviews 1.5, notifications 1.5, dispute and refund tooling 1.5, admin panel 4, backend 3, customer app shell and store release 2, design 5. That totals 42 person-weeks; with 25% on top, about 53 person-weeks: roughly $106,000 at $50 an hour and $318,000 at $150 an hour.
3. Two apps, held payments and live operations
Separate customer and provider apps, provider document checks, funds held until the job is confirmed complete, live location of the provider, chat with photos, a staged dispute process and an admin panel with finance reporting.
Accounts 3, provider onboarding 4, search 4, location with live tracking 3, booking flow 7, availability 3, split payouts 5, hold and release 2, messaging 4, reviews 2, notifications 2, disputes 3, admin panel 6, backend 4, two app shells 3.5, dedicated provider app 5, design 8. That totals 68.5 person-weeks; with 25% on top, about 86 person-weeks: roughly $172,000 at $50 an hour and $516,000 at $150 an hour.
This is a reasonable second-year product. As a first release it is usually a mistake, because almost none of the extra 60-plus person-weeks over example 1 tells you whether customers and providers want to meet on your platform.
How to cut scope without breaking the product
| Cut | What you do instead | Approximate saving |
|---|---|---|
| Build one side first | Launch a useful tool for providers (a booking page, a catalogue) or recruit supply by hand and build only the customer side | Often a third of the project |
| Provider web portal, not a provider app | Responsive web pages, email or SMS alerts for new orders | 5–8 person-weeks |
| No in-app messaging | Reveal phone numbers after booking, or relay by email | 2–4 person-weeks |
| Manual disputes | A support email address and refund buttons in the admin panel | 1–2 person-weeks |
| Admin-created listings | Your team enters providers; self-service onboarding comes later | 1–3 person-weeks |
| One city, one category, one currency | Hard-code what would otherwise be configurable | Spread across every block |
| Web before apps | A responsive web app, or a progressive web app where that is enough | About 2 person-weeks per app, plus device testing and store release work |
The rule behind the table: automate what happens on every order, and do by hand what happens on one order in fifty. Manual operations do not scale, and at launch that is not a problem you have. The exception is money. Refund and payout logic is painful to retrofit, so get the payment model right even in the smallest version.
What not to cut: the admin panel. In a marketplace it is how you correct a wrong booking at nine in the evening without asking a developer to edit the database.
The chicken-and-egg problem, briefly
Customers will not come without providers and providers will not stay without customers. Software does not solve this; concentration does. Pick one area and one category, recruit supply personally, and consider giving providers something useful before demand arrives. It is worth testing whether either side cares before paying for any of the above, and our guide to validating an idea before building covers cheap ways to do that. A spreadsheet, a form and a payment link can run a marketplace for its first twenty orders.
Running costs
| Item | How it is charged |
|---|---|
| Payment processing | A percentage plus a fixed fee per transaction, set by the provider and the card type |
| Marketplace payment product | Additional fees for connected seller accounts and payouts on most providers; read the pricing page for the exact model before setting your commission |
| Chargebacks and fraud | A fee per dispute plus the lost amount; decide in your terms whether the platform or the provider bears it |
| Hosting, database, file storage | Roughly $50–$400 per month at early scale |
| Maps, geocoding, SMS, email, push | Metered. Maps and SMS grow fastest with usage |
| Identity or document verification | Per check, if you verify beyond what the payment provider does |
| Store accounts | Apple Developer Program $99 per year; Google Play $25 one-off |
| Support and operations | Staff time. For a young marketplace this is usually the largest running cost |
| Maintenance | Plan on 15–25% of the build cost per year, as set out in our breakdown of post-launch app costs |
Check your unit economics against these early. If your commission is 12% and payments cost you around 3% of the order value, a quarter of your revenue is gone before hosting or support. How the platform itself earns money, whether by commission, provider subscriptions or paid placement, is discussed in our overview of app revenue models.
Getting a quote you can compare
- Describe one order from start to finish, from both sides, including what happens when it is cancelled, disputed or refunded.
- State the payment model: who pays, when, who receives what, in which countries and currencies.
- Mark each block in the table as first release, later or never.
- Ask each vendor which payment product they would use and whether they have integrated marketplace payouts before.
- Ask for the admin panel to be itemised. A quote that does not mention one is incomplete.
For general app budgeting beyond marketplaces, see what a mobile app costs to build. If you would like BBR to look at your scope, the mobile app development page explains how we estimate, and the MVP service page describes how we cut a first release down to what it needs.