People assume this category is finished because food delivery and ride hailing are settled. They are, in the three verticals everyone can name. What is not settled is everything else: trades, cleaning, tutoring, equipment hire, veterinary care, freight, childcare, salon services, medical transport, agricultural contracting. The model is proven, the infrastructure is commodity, and the remaining differentiator is execution, which is exactly the condition that produces design work. The difficulty is that you are not designing an app. You are designing two products with opposite priorities that must feel like one company.
Two products, one brand
The first structural decision is that the consumer app and the provider app are separate products with separate goals, and pretending otherwise causes most of the failures in this category.
The consumer wants to stop thinking
Someone booking a service wants speed, confidence and a price. They are not interested in the mechanics of matching, they do not want to compare fourteen providers, and they will abandon at the first moment of uncertainty. Their measure of a good experience is that the problem went away.
The provider wants earnings and control
The person on the other side is running a business. They care about how much a job pays, how far away it is, whether it fits their schedule, when they get paid, and whether accepting it will create a dispute later. They will use the app for hours a day, often while working, and their tolerance for friction is far lower than a consumer’s because it costs them money.
Where the conflict shows up
Every meaningful decision has opposite optima. Consumers want low prices; providers want high earnings. Consumers want instant availability; providers want predictable schedules. Consumers want free cancellation; providers want compensation for a wasted slot. The design job is not to split the difference reflexively but to decide, deliberately and in writing, which side each rule favours and why, then keep those decisions consistent across the product.
Products that leave this implicit end up with a consumer app that promises what the provider app cannot deliver, and the gap becomes support tickets.
The cold start problem is a design problem
A marketplace is useless until both sides exist, and the interface can either mask that or expose it brutally.
Do not launch a map with three pins
Showing supply directly when there is barely any supply is the most common early mistake. An empty map or a list with two providers tells the visitor the product does not work, and they will not return to check again.
The alternatives are well established. Take the request first and match behind the scenes, so the user experiences a promise rather than an inventory. Constrain launch to one neighbourhood or one vertical so density is real within that boundary. Or operate the supply side manually at first, which is invisible to the consumer and entirely legitimate.
Design the honest waiting state
If matching takes time, say so, show progress, and give a realistic window. “Finding someone, usually under ten minutes” is a workable experience. A spinner with no context is not, and it is where early marketplaces lose their first users. The honest wait is a specific case of designing what happens when a screen has nothing to show.
Seed the provider side with a reason to stay
Providers who sign up to an empty marketplace and receive no jobs churn immediately and are hard to win back. Either guarantee minimum earnings during launch, onboard providers only as demand appears, or be explicit that this is early and pay them for the inconvenience. Silence is the one option that reliably fails.
The consumer flow, decision by decision
The path from intent to booking is where conversion is won, and each step has a known failure mode.
Ask the minimum before showing value
Requiring an account before a price is the single largest source of drop off in this category. Let people specify what they need and see availability and cost before signing up, and take the account at the point of commitment when motivation is highest. Every field before that is a toll on a decision the user has not yet made.
Make the request specific without making it long
The tension is that better matching needs more detail, and more detail means more friction. The resolution is progressive: ask the two or three things that determine feasibility and price, then collect the rest after booking. A cleaning job needs property size and date. It does not need the customer’s preferred products before they know whether anyone is available.
Show the price the way it will be charged
Surprise fees at the final step are the most reliable way to lose a booking and generate a bad review simultaneously. Show the total, including service fees, travel and tax, as early as it can be calculated. If the final amount can vary because the job might take longer, explain the mechanism and the cap in plain language before booking, not in the receipt.
Confirm with certainty, not optimism
The confirmation screen must say what happens next, when, and what to do if it does not. “Booked” is not a confirmation. “Marek will arrive between 2 and 4pm on Thursday, and you will get a message when he sets off” is.
The provider flow, which decides your supply
Supply is harder to acquire than demand in most marketplaces, and the provider app is what retains it.
Onboarding is a verification funnel
Providers must prove identity, qualifications, insurance and sometimes background checks before they can work. This is inherently slow, and the design task is to keep people engaged through a process with waiting in it: show every step and its status, allow partial completion, explain why each document is needed, and never leave someone wondering whether their application is alive.
The single biggest improvement available is telling providers how long each stage takes and notifying them at each transition, which converts an anxious silence into a process.
Job offers must be answerable in seconds
A provider looking at their phone between tasks needs pay, location, distance, duration and customer rating at a glance, with accept and decline as large targets. Anything requiring a scroll to evaluate will be declined by default. If there is a response timer, it must be visible and fair, because a timer that expires while the screen is loading is how providers learn to distrust the platform.
Earnings must be legible and never surprising
The most damaging thing a marketplace can do to its supply is make payment confusing. Show gross, fees, and net for every job. Show when money will arrive. Make the history exportable, because these are self employed people who need it for tax. Any change to the fee structure needs communicating before it happens, in the app, in plain terms.
Ambiguity here reads as dishonesty even when it is only bad design, and it is the same principle that governs any interface where money is involved.
Respect the schedule
Providers have lives. Availability controls should be easy to set and genuinely respected, and the product should never punish someone for declining work outside their stated hours. Systems that quietly penalise unavailability produce burnout and churn, and the cost of replacing supply is far higher than the value of one covered job.
Trust mechanics, which are the actual product
In a marketplace, the platform sells confidence between strangers. The mechanics that create it deserve as much design attention as the booking flow.
Ratings that mean something
Five star systems compress into a narrow band where everything is either 4.8 or a disaster, which carries almost no information. Better approaches ask specific questions (was it on time, was the work as described) and show recency, since a provider’s last ten jobs matter more than their lifetime average.
Reviews must be two sided and released simultaneously, or both parties inflate to avoid retaliation. And a single bad review should not end someone’s livelihood, so design the appeal route before you need it.
Show identity proportionally
The consumer needs to know enough to feel safe: a real name, a photo, verification badges, relevant qualifications, how long they have been active. They do not need a home address or a phone number, and providers need protection from consumers too. Number masking for calls and messages should be the default in any product where strangers meet in person.
Make safety visible
Where the service happens in a home or a vehicle, safety features need to be present rather than buried: sharing an arrival with a friend, an in app emergency route, a clear reporting mechanism. This is proof, not decoration, which is the same reason honest social proof outperforms badges.
The moment of contact, which most products under design
The transition from booked to happening is where marketplaces are judged, and it is usually the thinnest part of the product.
The consumer wants to know that someone is coming, who they are, and when they will arrive. The provider wants to find the place, start on time and record what happened. Both need messaging that works when one of them is driving.
Live location has to be handled thoughtfully. Consumers value it enormously; providers experience it as surveillance if it runs outside working hours. Share location only during an active job, make that boundary explicit to both sides, and stop the moment the job ends.
Design the arrival edge cases, because they are common rather than rare: nobody home, wrong address, gated access, the job being different from what was described. Each of these needs a path that ends in a decision rather than a phone call to support.
Cancellations, no shows and disputes
This is the unglamorous core of marketplace design and it determines whether the unit economics work.
Write the policy before designing the screen
Who pays when a consumer cancels an hour before? What happens when a provider does not arrive? What if the job takes twice as long as quoted? These are business decisions with interface consequences, and designing the screens before the policy exists produces contradictory rules across the product.
Whatever the policy, state it at the point of booking rather than in terms and conditions. A cancellation fee that appears only when someone cancels is experienced as a trap even when it was technically disclosed.
Give disputes a structured path
Free text complaint forms produce unresolvable arguments. Structured disputes with categories, evidence upload, timestamps and a clear timeline resolve faster and more fairly. Both sides need to see status, because silence during a dispute is what turns a disagreement into a public review.
Design for the small percentage
Disputes affect a minority of jobs and consume a majority of support time. Investment here does not show up in a portfolio but shows directly in operating cost, which is why mature marketplaces put serious design effort into it and early ones almost never do.
Payments, payouts and the money design
Money moves in two directions and both need care.
Consumers expect to pay the way they pay everywhere else, with saved methods, and to receive a clear receipt. Where the final amount is uncertain, an authorisation and later capture is standard, but the interface must explain it, because a pending charge that differs from the quoted price generates support contacts and chargebacks.
Providers care most about payout timing. Faster payouts are a genuine competitive advantage in categories where operators are cash constrained, and instant payout for a small fee is a feature providers will actively choose a platform for. Show pending versus available balance unambiguously, and never let a payout fail silently.
Tipping, where it applies, should be designed honestly: prompted after the service rather than before, never with a coerced default, and passed through transparently.
Search, matching and how much choice to offer
There are two models, and picking the wrong one for the vertical creates permanent friction.
Automatic matching works when the service is standardised and speed matters more than selection. A ride is a ride. The consumer states a need and the platform assigns.
Browse and choose works when providers are genuinely different and the relationship matters: tutors, trainers, contractors, groomers, therapists. Here the consumer wants profiles, portfolios, specialisms and reviews, and removing that choice feels like being assigned a stranger.
Many verticals need a hybrid: a recommended match presented first, with the option to browse for people who want it. If you offer browse, the filtering has to be good, and the list has to be scannable on a phone, which is a navigation and hierarchy problem more than a search problem.
The operations console nobody scopes
Every marketplace needs a third interface: the internal tool for the people running it. Support agents resolving disputes, operations staff managing supply, finance handling payouts.
This gets left out of nearly every brief and then built badly under time pressure, which means the company’s own team works with the worst software it ships. Since support cost is one of the largest line items in a marketplace, a good console pays for itself quickly. The design vocabulary is closer to an operations dashboard than a consumer app, and our own work on that kind of surface is visible in an operations grade admin system.
Notifications, and the two very different inboxes
Both sides live on notifications, and they need opposite treatment.
The provider inbox is operational
A job offer that arrives silently is a job lost, so provider notifications need to break through: sound, priority delivery, and repeat if unanswered within the response window. These are not marketing messages, they are work, and providers will tell you directly that missing them costs money.
The corollary is that everything non urgent must be quieter. If earnings summaries and product announcements arrive with the same urgency as job offers, providers mute the app entirely and then miss the offers. Separate the channels at the operating system level so a provider can silence news without silencing work.
The consumer inbox is reassurance
Consumers need far fewer messages and different ones: booked, on the way, arrived, completed, receipt. Each should carry enough detail to be useful without opening the app. Anything beyond that transactional set needs to earn its place, and promotional messages in the same channel as arrival alerts is how a product loses permission for both.
Quiet hours are not optional
A job offer at 3am for a service that starts at 9am is a design failure. So is a promotional push to a provider on their day off. Respect stated availability in the notification layer, not just in the matching layer, because the phone buzzing is what people actually experience.
Geography, and why the map is harder than it looks
Location is the substrate of most on demand products, and it is a deceptively deep design area.
Address entry is the first trap. Autocomplete is essential, but so is handling the cases it fails on: new builds, rural properties, informal addressing, apartment blocks where the pin lands on the street. Let people drop a pin, save notes for the driver or technician, and store the corrected version for next time so the same mistake is not repeated on every booking.
Service area definition matters commercially. A consumer just outside the boundary should be told clearly rather than shown an empty result, and ideally offered a waitlist, because those requests are the data that tells you where to expand.
Travel time is not distance. A provider ten kilometres away across a bridge at rush hour is further than one fifteen kilometres away on an open road. Matching on straight line distance produces late arrivals and unhappy providers who took a job that did not pay for the travel, and the interface should show travel time rather than distance wherever a decision depends on it.
Pricing models and the design each one forces
The commercial model determines a large part of the interface, and it should be settled before design begins.
Fixed price per job is the simplest to design and the easiest for consumers to trust, but it needs careful scoping questions up front and a clear policy for when the job is bigger than described. Hourly pricing needs a visible timer, an agreed minimum, and a mechanism for approving overruns before they happen rather than presenting them on the invoice. Quote based models, common in trades and freight, need a whole additional flow: request, multiple responses, comparison, acceptance, and that comparison view is where the design effort concentrates.
Surge or dynamic pricing deserves particular caution. It is commercially effective and it is the single most resented mechanic in this category. If you use it, explain it before the booking rather than after, never let it appear as an unexplained change between screens, and consider capping it in situations where it will read as exploitative. The reputational cost of getting this wrong outlives the revenue.
Regulation, classification and the constraints you inherit
Marketplaces sit in a legal grey area that varies by market, and design decisions can move a business across a line it did not intend to cross.
Worker classification is the most consequential. The more the platform controls how, when and at what price someone works, the more likely they are to be treated as an employee rather than a contractor in many jurisdictions. Features like mandatory acceptance rates, forced schedules and platform set prices all push in that direction, and product teams routinely add them without knowing they carry that weight. Get advice before designing control mechanics, not after.
Beyond that, expect vertical specific rules: licensing and insurance verification in trades, background checks for anything involving children or vulnerable people, food safety in delivery, professional registration in health services. Each becomes an onboarding requirement, a badge in the consumer interface, and an expiry date somebody has to be reminded about. Certificate expiry handling is a small feature that prevents a large problem, and almost nobody scopes it initially.
The web side, which most marketplaces need too
Building a marketplace as an app only product is a common and expensive mistake.
Consumers discover services through search, and search results lead to web pages rather than app installs. A marketplace without indexable pages for its verticals and locations has cut itself off from the cheapest acquisition channel available to it, and paid acquisition for a low frequency service is brutal. The provider side is different: providers use the app daily and will install it happily, because it is their work.
So the usual shape is a web presence that handles discovery and first booking, and apps that handle repeat use and provider operations. That is a strategic decision with real budget implications, and it is worth settling with a clear head before anyone commits, which is exactly the app versus website question applied to a two sided business.
Measuring the right things
Marketplaces have a specific set of numbers, and vanity metrics are especially misleading here.
Liquidity is the one that matters: what proportion of requests get filled, and how fast. High signups with low fill rate is a failing marketplace with good marketing. Watch provider retention at thirty and ninety days, because supply churn is the quiet killer. Watch repeat booking rate, since acquisition costs mean most marketplaces only work on repeat behaviour. And watch the ratio of disputes to completed jobs as a direct proxy for how well the product sets expectations.
Instrument all of it before launch, because a launch period with no data cannot be reconstructed.
Keeping the two apps consistent without merging them
Two products, one company, and a limited team. The way this stays coherent is a shared design system rather than discipline.
Tokens for colour, type and spacing should be identical across both apps, and the shared primitives (buttons, inputs, sheets, status chips, money formatting, date and time formatting) should be built once. What differs is density and hierarchy: the provider app is denser, more utilitarian and optimised for repeat operation, while the consumer app is lighter and optimised for a first time user who will not read anything.
Status vocabulary is the detail that most often drifts. If a job is “accepted” in one app and “confirmed” in the other, support conversations become translation exercises and both sides lose confidence. Define one set of states, name them once, and use those names in the interface, the notifications, the emails and the internal console.
The same applies to time and money formatting. A provider seeing 14:00 and a consumer seeing 2pm is fine as a locale choice; the same user seeing both in one flow is not. These are exactly the small inconsistencies that accumulate into the kind of design debt that slows every future release, and building the shared layer early is what prevents it.
What we would build first
One vertical, one city, one direction of the flow done properly. Take the request, match it manually if necessary, deliver the job, handle payment, and learn what actually breaks. Automation follows evidence.
Resist building both apps to full fidelity before a single real job has been completed. The provider app in particular is best designed after watching providers work, because the constraints that matter, gloves and vans and bad signal and awkward customers, are not visible from a desk. Half a day observing is worth more than a month of internal debate, and the narrow first version is the same discipline that governs any MVP.
Supply quality, and the moderation nobody plans
A marketplace inherits responsibility for people it did not hire, and the interface is where that responsibility becomes visible.
Poor providers damage the brand far more than good ones build it, because a single bad experience in someone’s home produces a review that outlives dozens of ordinary jobs. That means the product needs a working quality loop: signals that surface a declining provider early (cancellation rate, late arrivals, dispute frequency, rating trend), a warning stage that is fair and specific, and a removal process that is documented.
Design the fairness into it. Automated deactivation based on a metric with no human review and no appeal is both ethically poor and commercially risky, because the same mechanism removes good providers having a bad month. Show providers their standing continuously rather than only when they are in trouble, so nobody is surprised, and make the thresholds explicit rather than secret.
On the consumer side, moderation matters too. Fake reviews, abusive messages and fraudulent bookings all need reporting routes and someone to act on them, which loops straight back into the operations console that most briefs forget to scope.
The failures we see repeatedly
Most of these are visible from the first week of a project, which is the encouraging part: they are scoping decisions rather than craft problems, and scoping decisions are cheap to change early.
An empty map at launch. Account creation before a price. Fees revealed at the final step. A provider app designed as an afterthought by people who have never done the job. Ratings that carry no information. No dispute flow, so support improvises. Payout timing that is unclear. Live location that runs when nobody is working. And an operations console built last, badly, for the people who use the product most.
Each one is a decision made early and paid for repeatedly. The pattern connecting them is that the consumer app gets the attention because it is the one shown in pitches, while the provider app and the operations console decide whether the business works.
If you are building a marketplace and want a straight read on which side to design first and where the policy decisions need making before any screens exist, describe the vertical and the two sides: hello@beconfidency.agency.
When the hard part is making two opposing products feel like one, that is exactly what our product design service is for.