Service marketplaces look simple. The booking logic is not.
Availability that stays true, prices that sometimes do not exist yet, providers whose credentials matter more than their star rating, and a category where the better the match the more likely you lose it. We build for all four.
Talk to someone who has built one.
Thirty minutes with a senior practitioner. Bring how a job gets priced and booked in your category, and we will tell you what it implies about scope, cost and platform.
The inventory is a person, and it is booked elsewhere too.
Most marketplace software assumes the thing being sold sits still and belongs to the platform's view of the world. A service marketplace sells time it does not control, at a price that sometimes does not exist yet, to a buyer who may never need you again once the introduction is made.
You are selling somebody's calendar.
Inventory in a service marketplace is a provider's time, and it is being consumed by things your platform cannot see. A plumber takes a job over the phone and your calendar does not know. Availability that is wrong twice loses you the provider, because the cost of a bad booking lands on them, not on you.
Half the time there is no price yet.
Plenty of services cannot be priced until someone has looked at the job. That turns your listing page into a request, your checkout into a quote, and your transaction into a negotiation with states. Platforms built around a fixed price and a buy button do not bend to this gracefully.
The better the match, the more likely you lose it.
This is the category where disintermediation is worst. Two people meet once, it goes well, they exchange numbers, and the next twelve jobs happen without you. That is not a policy failure you can write your way out of. It is a product problem, and it should shape the build from the start.
Four things that decide whether a service marketplace works.
Each is available on its own. Together they are the difference between a working service platform and a directory that takes payments.
Scheduling and availability
Calendars that reflect a working day, not an idealised one.
Provider working hours, buffer between jobs, travel time between locations, and two-way sync with the calendar they already live in. The hard part is not showing open slots, it is keeping them true when the provider's real life happens elsewhere. We build the sync, the conflict handling, and the rescheduling flow that does not require your support inbox.
- Provider availability with working hours and buffers
- Travel-time and service-area aware slotting
- Two-way external calendar sync
- Rescheduling and cancellation flows with policy enforcement
- No-show handling for both sides
Quotes, pricing and adjustments
Fixed price where you can, a real quote flow where you cannot.
Some jobs price off a rate card, some need a site visit, and some change once the work starts. We build whichever your category needs, including the awkward one: adjusting the amount after the job is done, with the buyer's agreement and without breaking the payment that was already authorised.
- Fixed, hourly and quoted pricing side by side
- Request-for-quote flow with revision states
- Post-job adjustments, extras and tips
- Deposits and staged payment on larger jobs
- Take rate modelling across job sizes
Provider vetting and credentials
In services, trust is licences and insurance, not just star ratings.
A five-star average from four reviews tells a buyer very little when a stranger is coming to their home. Licences, insurance, background checks and references tell them a great deal. We build the verification your category actually requires, the expiry tracking that keeps it current, and the onboarding that gets a provider from interested to bookable without a week of email.
- Credential, licence and insurance capture with expiry tracking
- Background check integration where the category requires it
- Structured provider profiles built for buyer confidence
- Guided onboarding with progress tracking
- Admin review and approval queue
Retention and anti-leakage
Making the platform worth staying on after the introduction.
We will say this plainly because most agencies will not: you cannot stop two adults exchanging phone numbers, and contractual anti-circumvention clauses are close to unenforceable at small job values. What works is making the platform genuinely easier than going direct — it holds the schedule, the payment, the records, the guarantee and the recourse. We build the things that make leaving cost the buyer something.
- Repeat booking and rebooking flows
- Payment protection and guarantee handling
- Scheduling and records both sides want to keep
- Leakage measurement by buyer-provider pair
- Loyalty and repeat-rate instrumentation
Eight to twelve weeks, in three phases.
Transaction design
We map one job end to end: how it is requested, how it gets priced, who confirms, what happens on the day, and what happens when it changes. For services the scheduling and pricing model decide most of the build, so this is where the expensive decisions get made cheaply. You get a written specification you either agree with or change.
Build
Design system, listings, availability, booking, payments, provider onboarding and admin. Weekly demos, so you see the thing working rather than reading status updates. AI handles the repetitive implementation work. Every architectural decision is made by someone who has shipped a marketplace before.
Launch
Soft launch with a controlled group of providers and buyers, first real jobs completed, and the operational tuning that only surfaces once real appointments are happening. Sixty days of bug coverage after go-live.
If three of these are true, this is the right starting point.
- You are matching buyers with people who do work, not with objects
- Booking depends on availability, and getting it wrong costs the provider money
- Some or all of your jobs need a quote before there is a price
- Provider credentials, licensing or insurance matter to your buyers
- You can name your first twenty providers, or you know exactly where they gather
- You would rather design the scheduling model now than rebuild it in month six
Service development is the wrong call if any of these is true.
- You are hiring people for projects rather than booking appointments. That is closer to a talent marketplace, and the trust architecture differs.
- The thing being booked is an object that comes back. See rental marketplace development.
- You have not confirmed providers will accept your take rate. Start with pre-development instead.
- Your platform is live and providers are leaking off it. That is a go-to-market conversation, not a rebuild.
- Your buyers are companies rather than individuals. See B2B marketplace development.