insights · strategy
July 24, 20269 min read
Two-Sided Marketplace MVP: Which Side Do You Build First?
StrategyMarketplace
Don Wishvantha
The short answer is supply. Here's why you build the seller side of a marketplace before the buyer side, and how we did exactly that shipping Autara.
tl;dr
Build the supply side first. In almost every two-sided marketplace the sellers are the harder, slower side to acquire, and the reason buyers show up at all. So you recruit a small set of high-quality suppliers, give them real tools, and only then open the doors to demand. When we built Autara, an Australian vehicle-care marketplace, we shipped the merchant side to feature-complete before the customer app, over sixteen months, merchant-first. Sequencing is also the cost decision: published 2026 guides put a simple single-loop MVP at roughly $15,000–$40,000 and a two-sided marketplace at $35,000–$70,000, and building both halves at once is how founders pay the higher number twice. This guide covers why supply-first is the default, the two situations where it isn't, what actually moves an MVP's price, and how to sequence a marketplace MVP so you're never building both sides at once.
Why “which side first” decides your whole MVP
Every marketplace starts with the same trap: the chicken-and-egg problem. Buyers won't come without sellers, and sellers won't stay without buyers. The instinct is to build both sides at once so neither is missing at launch. That instinct is what kills most marketplace MVPs.
How much does it cost to build an MVP?
Published 2026 cost guides put a simple single-loop MVP, one type of user and one core loop, at roughly $15,000–$40,000, and a two-sided or multi-sided marketplace MVP at $35,000–$70,000. US agencies routinely quote well above both. Those are market ranges rather than anyone's price list, and the full published span runs from around $5,000 for a stripped single-feature build to $250,000 for something enterprise-grade, which is why an average is close to useless as a planning number.
The gap between those two ranges is what this article is really about. A marketplace costs roughly double a single-loop MVP because it is really two products sharing one backbone, and each side needs its own onboarding, its own screens, and its own reason to stay. Build both halves on one early-stage budget and you get two half-finished apps, neither good enough to attract its side. Sequencing the two sides is how you spend that budget once instead of twice.
We don't quote a flat figure before understanding the problem, and you should treat any studio that does as guessing. We scope in fixed phases and price each one before it starts, so the number you're committing to is always the next phase rather than the whole build. Use the market ranges above to sanity-check a quote, not to budget from.
What actually moves the number?
Four things do most of the work: how many distinct types of user you serve, whether you need native mobile as well as web, how much of the product touches payments or compliance, and how much of it has to talk to systems you already run. A marketplace is expensive because it usually triggers all four at once. Everything else, the framework argument included, is noise next to those.
| Cost driver | Why it adds | What it looked like on Autara |
|---|---|---|
| Distinct user types | Each one is a separate product surface: onboarding, permissions, screens, support | Two apps, merchant and customer |
| Native mobile as well as web | More platforms to build, test, ship and keep in review | iOS, Android and web from one backbone |
| Payments and compliance | Split payments, payouts and verification are slow, high-stakes work you cannot half-build | Stripe Connect, plus ABN, insurance and licence checks |
| Integrations you don't control | Someone else's data model, someone else's uptime, and your test suite carrying both | Automated image moderation and business verification |
What does an MVP cost to run before it launches?
Close to nothing, if the architecture is chosen for it. Autara ran at close to zero infrastructure cost before launch because the stack is serverless and nothing sits idle waiting for traffic that hasn't arrived yet. It's worth separating the two numbers when you budget: build cost is the one that decides whether you can start, and running cost, for a pre-launch product, mostly shouldn't be a line item you think about.
The default answer: build supply first
In most marketplaces the supply side is the constrained one. Good sellers are scarce, they take real effort to recruit and verify, and their inventory is the entire reason a buyer opens your app. Demand, by contrast, is comparatively easy to point at something once that something exists. The rule of thumb every experienced marketplace founder repeats: fill the store before you open the doors.
“Sellers will wait around for buyers. Buyers won't wait around for sellers.”
The practical move is to recruit a small group of “anchor” suppliers, five to fifteen high-quality sellers whose presence makes the marketplace feel worth visiting, using incentives like reduced commission, free listings, or early-partner status. Give them tools good enough that they'd use you even before the buyers arrive. Then, and only then, turn on demand.
| Supply-first (default) | Demand-first (rare) | |
|---|---|---|
| Build first | Seller tools, onboarding, listings, payouts | Buyer discovery + booking |
| Best when | Sellers are scarce or high-value | Sellers are an abundant commodity |
| Cold-start tactic | Anchor vendors, fee holidays, concierge onboarding | Pre-aggregate demand, waitlists |
| Main risk | Launching to thin demand | Sellers churn before buyers arrive |
| Example | Autara, merchants first | Some attention / ad marketplaces |
When to build the demand side first instead
There are two honest exceptions. First: when supply is an abundant commodity and the buyers are the scarce, valuable side, if any seller will happily join the moment there's demand, then demand is your real constraint and you build for it first. Second: when you can aggregate demand cheaply (a waitlist, an audience, an existing channel) and use that demonstrated demand as the pitch that recruits supply. Both are rarer than founders think. If you're unsure which side is scarce, it's almost always supply.
How we sequenced it for Autara
Autara is a two-sided vehicle-care marketplace connecting Australian car owners with vetted detailing and wrapping merchants. We built the merchant side to feature-complete before the customer-facing app: guided onboarding with business verification (ABN, insurance, licences), Stripe Connect for split payments and payouts, full service management, and automated image moderation, the whole onboarding flow backed by 90+ automated tests. Built across iOS, Android and web over sixteen months, merchant-first.
Two decisions made supply-first affordable. The architecture is serverless (AWS Lambda, AppSync), so infrastructure costs stay near zero while the platform recruits its first merchants. And because the merchant tools were genuinely useful on their own, early sellers had a reason to onboard before a single buyer existed. That's the point of building supply first: the seller side has to stand up on its own.
A supply-first marketplace MVP checklist
- Recruit 5–15 anchor suppliers before you write a line of buyer-facing code.
- Give suppliers real tools, onboarding, listings, payouts, not a spreadsheet and a promise.
- Build trust signals early: identity/business verification, secure payments, reviews.
- Make one real transaction possible end-to-end. That first transaction is the whole MVP.
- Instrument supply liquidity before opening demand, know your inventory is real.
- Keep infrastructure cheap (serverless) until both sides exist.
Sequence the sides, prove one real transaction, and keep your infrastructure cheap until demand is real. Do that and the chicken-and-egg problem stops being a paradox and becomes a schedule.
frequently asked
Which side of a two-sided marketplace should you build first?
Supply, in most cases. Sellers are usually the scarce, high-value side and the reason buyers show up, so you recruit a small group of quality suppliers and give them working tools before opening the marketplace to demand.
Why build the supply side of a marketplace first?
Because buyers won't visit an empty marketplace, and sellers are the harder side to acquire and verify. Sellers will wait around for buyers to arrive; buyers won't wait around for sellers. Build the store's shelves before you open the doors.
How much does it cost to build an MVP?
Published 2026 cost guides put a simple single-loop MVP at roughly $15,000–$40,000 and a two-sided or multi-sided marketplace MVP at $35,000–$70,000, with US agencies quoting considerably higher and the full published span running from about $5,000 to $250,000 depending on scope. Those are market ranges, not a price list, and scope is what decides where you land in them. For a marketplace, building both sides at once on an early budget is what blows it, sequencing the sides is how you avoid paying twice.
What makes one MVP cost more than another?
Four things do most of it: how many distinct types of user you serve, whether you need native mobile as well as web, how much of the product touches payments or compliance, and how much of it has to integrate with systems you already run. A marketplace is expensive because it usually triggers all four at once. Infrastructure is rarely the driver, Autara ran at close to zero infrastructure cost before launch because the stack is serverless.
How long does it take to build a marketplace MVP?
Scope decides it, and a multi-app marketplace is a different order of work from a single product. Autara spans iOS, Android and web, built over sixteen months, merchant (supply) side first.
When should you build the demand side of a marketplace first?
Only when supply is an abundant commodity and buyers are the scarce, valuable side, or when you can cheaply aggregate demand (a waitlist or existing audience) and use it to recruit supply. Otherwise, default to supply-first.