Should you launch one side of your marketplace first?

Why launch one side of a marketplace first?

Because you cannot fill both sides on the same day, and whichever side arrives first judges the platform by what it finds. Launching one side first lets you get that side ready before the other side ever looks.

A marketplace is a promise to two groups at once. Customers come because providers are there. Providers come because customers are there. On launch day, neither is true. If you open both doors together, the first customers find nobody to book and the first providers find nobody booking. Both decide the platform is empty, and most do not come back.

Launching one side first breaks that loop. You bring one side in, get it ready, and open the other side when there is something real to find. It is also often the fastest way to go live, because the first working version can concentrate on one side’s experience instead of splitting the effort evenly.

Which side of the marketplace should launch first?

Launch the side the other side comes for. In most service marketplaces that is supply, meaning the providers: workers, riders, pharmacies, drivers.

Three questions decide it for a specific marketplace:

Which side does the other side come for? Customers open a home services app to find a worker. Workers have no reason to open it until customers exist. Start with the side that is the reason to visit.
Which side takes longer to get ready? Providers usually need signing up, checking, and setting their prices, areas and hours. A customer can sign up in a minute. Start with the side that needs lead time.
Which side will wait? A provider who is verified and set up can be asked to wait for launch. A customer who finds nothing will not wait at all.

If the answers point in different directions, the second question usually wins, because lead time cannot be made up on launch day. We tell you which side and why for your marketplace. It comes out of the five questions we answer in phase one, described on how we work.

Why does supply usually come first in service marketplaces?

Because a customer who finds no provider leaves at once, while a provider who is set up and waiting can be kept. An empty customer app wastes whatever you spent bringing customers in.

Providers in a service marketplace also carry most of the setup work. They need an account, identity checks, a category, skills, rates, a working area and a way to be paid. None of that can happen in the moment a customer is searching. Doing it before customers arrive means the first search returns real people with real prices.

There is a quieter reason too. Onboarding providers first tells you whether you can get them at all. If you cannot sign up providers in the areas you plan to open, you have learned that before paying for the full platform, not after.

When should customers come first?

When customers are the scarce side, or when the service can be supplied some other way at the start. Some marketplaces are led by demand.

Customers first can make sense when:

Providers will join quickly once customers exist. If you can show providers a waiting list of real customers, signing them up gets easier.
You, or a small group you manage, can fulfil the first orders. The platform works as a marketplace for the customer while, behind it, your own team does the work. Outside providers come in later.
The supply already exists and only needs connecting. Where providers are established businesses, the hard part is persuading customers to use a new app.

Customers first is less common in service marketplaces. When it fits, it is usually because the supply problem has already been solved another way.

What does “launch one side first” mean in practice?

It means opening the platform to one group before the other can use it. It does not mean building one app and forgetting the other. In a supply-first launch, providers are onboarded and ready before customers can place an order.

The order of work usually looks like this:

The provider app and the admin console go live first. Providers can register, upload what verification needs, set their categories, prices and working area, and see how they will be paid.
Your team onboards providers. You approve or reject each one in the console, chase incomplete profiles, and check coverage by area and category.
The customer side is built alongside, but closed. It may be in testing with a small group, or behind a waiting list.
Customers are let in once there is supply to serve them, often one area or one category at a time.
Both sides run on the same rules from the first real order: payments, cancellations, ratings and disputes.

Do you need both apps finished at launch? No. We will tell you which one to build first. What you do need is both sides designed together, because the provider’s price and availability are exactly what the customer sees. The customer app, provider app and console that make up a marketplace are listed on marketplace app development.

What must the admin console still do when only one side is live?

Almost everything. The admin console is the web dashboard your team uses to run the marketplace, and a one-sided launch leans on it harder, not less.

With only providers live, the console still has to handle:

Provider approval and verification, with a record of who was checked and when.
Profiles, categories and coverage, so you can see where you have providers and where you do not.
Commission and pricing rules, set in the console rather than in code, so you can change them without a new release.
Payout setup, so providers know how and when they will be paid before they do any work.

When customers arrive, the same console takes on orders, refunds, disputes and matching. Automatic assignment with manual override is the default, so your team can always step in. None of this waits for a later phase. If the first real order can go wrong, the console has to be able to put it right. Shorter answers on running a marketplace are in marketplace operations.

What is the risk of launching one side first?

The risk is that the side you launched waits too long and leaves. A marketplace with providers and no customers dies, and so does the reverse.

Both sides have to be worth showing up for. Providers who sign up and then hear nothing stop answering. Providers who get their first jobs stay. So a one-sided launch needs a date for opening the other side, and a reason for providers to stay while they wait: a clear launch date, a finished profile, and first access to jobs in their area.

Other risks to plan for:

Building the closed side too late. If the customer app is an afterthought, the opening slips and the waiting side goes cold.
Onboarding in the wrong places. Providers spread thinly across a whole country serve nobody well. Concentrate on the areas and categories where you will open first.
Designing for one side only. Payments, refunds and ratings affect both sides. They have to be designed for both from the start, even if only one side sees them at first.

This is a product decision before it is a technical one, and it is one of the first things we ask about.

How does a one-sided launch fit into build phases?

It shapes the first working version, not the whole platform. You decide which side leads during scope, and the first working version proves the core loop with real data.

We build in three phases. Phase one is scope and price: the five questions answered, the build written down, and a named list of what we are not building. Which side launches first is decided and written down there. Phase two is the first working version: the core of the platform running with real data, and the point where you decide whether to continue. For a supply-first marketplace, that means providers onboarded and the loop working end to end. A customer can book, a provider can do the job, and you can see it in the console. Phase three is everything after, in phases of the same shape, each priced before it begins.

You pay per phase. Stop after any phase and you keep everything we built. For timing, see how long it takes to build a marketplace.

Worked example: why does the supply side decide FindWorker’s customer experience?

FindWorker is our own home services marketplace in Pakistan, and we operate it. Workers set their own price and customers choose, which makes the worker side the thing a customer judges the platform by.

Follow what a customer does. They pick a category, see workers with their skills and rates, check who is nearby on a live map, and book. Every one of those steps depends on the worker side being complete first. A category with no workers is a dead end. A worker with no rate cannot be chosen. A worker with no working area cannot be matched by location.

Because the provider sets the price, the provider side carries more than it would on a platform that fixes prices centrally. A worker needs a profile, a category, skills, rates and a payment setup before any customer can see them. FindWorker pays by milestone, so a worker also needs to understand when the money is released.

Running FindWorker means the problems of both sides are ours: providers not showing up, cancellations, no-shows, disputes and payouts. That is why, on the builds we take on, the provider side, verification, and the no-show and dispute rules are written into phase one, not added as polish after launch. The same thinking applies to how the money moves, which the payments and payouts guide covers.

What this means for your estimate

Launching one side first changes what goes into the first working version, and so the first build phase you pay for. It does not remove the console, the payments or the rules both sides share.

Before you use the planner, have a view on three things:

Which side does the other side come for?
Which side needs the most setup before it is ready?
Can your own team fulfil the first orders, or do you need outside providers from the first day?

The estimate planner walks through questions like these and produces a brief. We reply with a tailored quote, usually within one business day. If you are not sure which side should lead, say so. Phase one exists to answer it. Pricing shows what every price includes and what costs extra.