Services marketplaces, built to survive the second transaction.

Supply model and category taxonomy

The first decision is what a provider actually is on your platform: an individual with a calendar, a company with several workers, or an agency reselling capacity. Each implies a different data model, a different payout arrangement and a different answer when something goes wrong on a job.

Category taxonomy is the second, and it decides how demand finds supply. Categories that are too broad produce irrelevant matches and wasted provider time. Too narrow and neither side has enough liquidity to transact. This is a marketplace design question with engineering consequences rather than a content exercise.

The output is a supply model that can express your real provider mix and a taxonomy that matches how customers actually describe what they need.

Matching, leads and quoting

There are two models and they produce different businesses. In a lead model the customer describes a need and several providers respond, which suits variable work where price cannot be known in advance. In a booking model the customer selects a defined service at a known price and confirms immediately, which suits standardized work and converts far better.

Platforms that try to be both without deciding end up with a quoting flow that is slow for simple jobs and a booking flow that cannot express complex ones. Choosing per category is legitimate; refusing to choose is not.

Lead economics deserve care. If providers pay for leads, the platform is incentivized to send more of them, and providers will leave if quality drops. Charging on outcomes aligns better and is harder to build, which is exactly why it is defensible.

Escrow, milestones and payment timing

Services money is held money. The customer pays before the work is verified and the provider is paid after, which means your platform holds funds it does not own, often across a boundary where the two parties disagree. In many jurisdictions that has regulatory weight, and the arrangement with your payment provider needs to reflect what you are actually doing.

Milestones make long engagements workable: the work is divided, funds are released in parts, and neither side carries the whole risk. Getting the state machine right matters because a milestone can be submitted, disputed, revised and resubmitted, and the money has to be unambiguous at every one of those points.

For local services the timing inverts - work happens first, payment follows - which changes the fraud surface entirely.

Trust: verification, insurance and reviews

Trust requirements scale with what can go wrong. A logo designer who disappoints costs a fee. A person entering a customer's home, caring for their animal or working on their electrics carries physical and liability risk, and the verification depth has to match that rather than a platform-wide default.

Identity, right to work, qualifications and background screening each have their own jurisdiction rules and re-check intervals, and documents expire. A platform that verifies once and never revisits will eventually dispatch someone whose certification lapsed a year ago.

Reviews are the mechanism that prices trust, which makes their integrity a security concern. Review manipulation is the most common attack on a services marketplace, and the defence is structural: only verified transactions can produce a review.

Scheduling and fulfilment

For anything performed in person, the calendar is the product. Provider availability, travel time between jobs, buffer periods, recurring bookings and cancellations that free capacity late are all part of one scheduling problem, and treating availability as a simple on-off flag produces double bookings and stranded providers.

Recurring services add a dimension most platforms handle poorly. A weekly dog walk or a fortnightly clean is a series with exceptions, not many independent bookings, and the customer expects to change one occurrence without unpicking the rest.

Retention design, or defending the take rate

This is the phase most builds skip and the one that decides whether the business compounds. Once a customer and a provider have completed a job successfully, both have an incentive to arrange the next one directly. Terms of service do not prevent it and enforcement attempts damage the relationship with the supply you depend on.

What works is making the platform genuinely worth the fee: guarantees and dispute cover the parties cannot arrange privately, payment protection that benefits both sides, scheduling and records that are simply more convenient than messaging, and for providers, a stream of new demand that only the platform supplies.

These are product decisions with engineering weight, and building them late means building them after the leakage has already been learned by both sides.

Launch and day two

One city or one category, with supply recruited before demand spend. A services marketplace with thin supply produces slow responses and bad first experiences, and the customers who have that experience do not come back to give it a second try.

Day two is dispute handling and payout queries, both of which arrive with the first completed jobs and need tooling rather than judgment. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.