Start with one transaction you can support
Launch with a narrow service, a small matching area and providers whose current capacity you can confirm. Uneven signup numbers are normal operating information: they tell you where requests may wait or providers may sit idle. A large directory does not demonstrate that a customer can find an appropriate provider, agree a time and receive the promised service.
Your first release should answer one question: can an eligible customer complete this particular transaction with an eligible provider, including recovery when something goes wrong? This guide proposes a first-transaction marketplace brief for that decision. It does not report a tested launch, customer results or measured demand. The operating rules and examples below are illustrative choices to review with your own team.
Define the smallest useful service boundary
Write a specific service promise before building matching screens. For a hypothetical cleaning marketplace, “a three-hour standard home clean in selected Cape Town suburbs” is clearer than “all home services across South Africa”. Define included tasks, exclusions, travel boundaries, service hours, equipment responsibilities and how customers describe their property. A limited package still needs a way to decline unsuitable requests.
Record who supplies the service and who is responsible for customer support. Decide whether the platform only introduces parties or also manages booking and collection. Do not describe the platform as an escrow service, employer or payment intermediary simply because it stores a provider balance. Those relationships require separate contractual and provider review.
Make a list of conditions that prevent a match: unavailable time, outside-area address, unsupported task, missing provider verification or insufficient capacity. Provide an honest unavailable response or a consent-based waiting list. Avoid showing a provider as bookable merely because their profile is published.
Separate provider eligibility from availability
Provider verification and current availability answer different questions. Verification concerns whether a provider meets your defined onboarding criteria. Availability concerns whether they can perform this service at the requested time and location. Neither proves the quality of a future job.
For the first cohort, an operator can confirm identity, contact details, service scope and coverage, then record bookable windows with a last-confirmed timestamp. Any insurance, registration or credential requirement should be appropriate to the service and expressly adopted as a platform rule; it is not a universal requirement established by this article. Collect only documents you have a defensible reason to retain.
Agree a refresh procedure. A proposed rule might remove unconfirmed time windows from matching after a defined period. Decide who can reinstate them and what evidence they need. Check travel time, equipment constraints and overlapping jobs. Availability should be revalidated when a provider accepts a request, because another channel may have consumed the slot after the directory was last refreshed.
Model the transaction before automating it
Use separate records or clearly separate state fields for the request, reservation, payment, fulfilment, refund and payout. A single status called “complete” cannot explain whether the customer paid, the provider attended or money reached the provider.
| Area | Example states | Evidence needed for the next step |
|---|---|---|
| Request | Submitted, awaiting provider, accepted, declined, expired | Provider response for the requested scope |
| Reservation | Available, temporarily held, confirmed, released | Atomic capacity check and an expiry time |
| Payment | Not started, pending, successful, failed | Validated gateway result matched to the expected amount and reference |
| Fulfilment | Scheduled, started, delivered, disputed, cancelled | Operational evidence appropriate to the service |
| Refund | Not requested, requested, processing, completed, failed | Provider confirmation of refund processing and reconciliation |
| Payout | Not eligible, eligible, pending, settled, failed | Contractual eligibility and verified settlement evidence |
This is a proposed model, not a claim about any gateway's event names. The brief should specify which actor can trigger each transition and what happens if an event arrives late. In an acceptance-first design, the provider accepts and capacity is temporarily reserved before the customer is invited to pay. Payment must complete within the reservation window; otherwise the slot can be released under the agreed rule.
A late successful payment after reservation expiry needs an exception path. It must not silently recreate a booking whose slot is now allocated elsewhere. Recheck availability, offer a customer-approved alternative or start the authorised refund process. A refund request is not proof that the refund completed. Likewise, recording provider earnings is not proof of a settled payout.
Choose a matching process the team can explain
For a small launch, manual assignment with a clear queue can reveal constraints before you invest in an algorithm. Record the eligible providers, exclusion reasons, response deadline and assignment decision. A customer should understand whether they have submitted a request or secured a confirmed appointment.
Do not always send every request to every provider. A proposed sequential approach can offer it to one eligible provider, wait until the response deadline and then try the next. A competing-offers approach requires an atomic acceptance rule so two providers cannot both acquire the same job. Neither method is automatically better: choose based on response time, fairness, capacity and operational workload.
Have an operator own unmatched requests. They need a bounded action list: confirm details, widen the time window with customer consent, decline an unsupported request or close an expired request. Marketing should promote the service and area you can currently support. Extra demand can worsen waiting times when the available cohort already lacks capacity.
Protect the transaction and its participants
A provider should see only the customer details needed for an assigned job, at the appropriate stage. A customer should see their own request and payment history. Support, finance and verification staff need different privileges; avoid giving every administrator unrestricted access to documents and payment controls. OWASP's authorization guidance recommends least privilege, deny-by-default access and permission validation on every request.
When using Supabase, database grants and row-level policies must match the intended access. Its row-level security documentation explains database-enforced row access and the distinction between grants and policies. Keep privileged keys on trusted servers and review server paths that bypass policies. Test exports and direct API requests as well as the visible screens.
Decide on gateway eligibility before promising a collection or payout model. The platform's country, legal entity, bank account, provider locations and service category can affect approval. Stripe's availability page currently lists South Africa through its extended network with Paystack; that listing does not establish access to Stripe Connect APIs or equivalent charge models. Obtain confirmation for the actual merchant and marketplace arrangement. Do not assume a gateway supports holding funds, arbitrary splits or delayed settlement.
Keep discovery pages separate from private journeys
Public service and area pages should describe real coverage and inventory without exposing addresses, private verification files or booking details. Customer requests, provider workspaces and finance screens require authenticated, authorised access. A search-engine directive does not provide that access control.
For a Next.js implementation, the Metadata API provides route metadata fields including titles, descriptions and robots directives. Use appropriate metadata for deliberate public landing pages, then inspect the actual rendered response. Keep private workspace URLs out of public navigation and sitemaps. Metadata should reflect what the page can truthfully offer, including when a service is unavailable in an area.
Complete the first-transaction brief
Copy this table into your discovery pack and fill it with decisions that have a named owner. A blank row is a launch dependency, not permission for a developer to guess.
| Decision | Required entry |
|---|---|
| Service boundary | Included work, exclusions and eligibility questions |
| Matching area | Supported locations and travel constraints |
| Provider readiness | Verification criteria, capacity evidence and refresh owner |
| Request handling | Matching method, response deadline and unmatched-request owner |
| Reservation | Capacity rule, expiry and late-payment recovery |
| Collection | Approved merchant, amount, currency and validation procedure |
| Fulfilment | Attendance evidence, completion rule and dispute route |
| Money exceptions | Cancellation, refund and payout ownership with separate states |
| Access | Role and object-level allow/deny tests |
| Expansion | Evidence to review before adding capacity or locations |
Hypothetical example and evidence calculation
Suppose a pilot receives 20 eligible requests in its agreed service area during a defined two-week period. Of those, 15 obtain provider acceptance, 13 complete payment within the hold window and 12 reach recorded fulfilment. These are invented teaching figures. Acceptance is 15/20, or 75%; end-to-end recorded fulfilment is 12/20, or 60%. Calling the payment completion rate “marketplace success” would conceal the unfulfilled request and the earlier unmatched demand.
Review every failed transition before changing acquisition. If five requests could not find an eligible provider, check time windows and geographic coverage. If two accepted requests never paid, inspect expiry and checkout failures. If one paid request was not fulfilled, investigate the service and recovery path. Small samples cannot establish a stable cancellation rate or predict expansion results. Use them to identify cases worth inspecting, and choose expansion criteria explicitly rather than adopting universal percentage targets.
Test interruptions before inviting the first customer
Run a complete journey with clearly labelled test accounts and gateway test facilities. Test two customers competing for the same capacity, a provider accepting after expiry, duplicate payment notifications, interrupted checkout, a successful payment arriving late and a cancellation after collection. Expected results should include the resulting records, user-visible status and operator task.
Try accessing another customer's booking and another provider's job through a direct URL or API call. Confirm that unassigned providers cannot download sensitive files. Test operator recovery when a notification is unavailable: staff must reconcile against the authoritative provider result without recording an unsupported success. Keep any real-money verification separately authorised, and do not treat sandbox success as production acceptance.
Frequently asked questions
Should we attract customers or providers first?
Recruit enough verified, available providers for the first narrow transaction, then acquire customers within that capacity. If demand exceeds coverage, manage the waiting list and response expectations. If providers are idle, investigate the service offer and qualified demand rather than expanding the directory indefinitely.
Can we take payment before provider acceptance?
It is a separate product and payment decision. Collection-first designs need explicit customer terms, a confirmation deadline and reliable rejection/refund recovery. The acceptance-first example here limits one source of risk, but still requires capacity holds and late-payment handling.
Is manual matching acceptable for launch?
Yes, when the team records decisions, meets its stated response expectations and can recover exceptions. Measure operator workload and inconsistent decisions before automating. The presence of an algorithm does not prove matching quality.
When should we expand the service area?
Review representative fulfilled and failed transactions, provider capacity, support workload and financial reconciliation. Set proposed expansion gates with named owners. Published profiles or raw signup counts alone do not demonstrate that the next area can fulfil requests.
If your business is preparing a marketplace launch, use the marketplace platform development brief to turn these decisions into a scoped product. Use the Discovery Phase Checklist to document unknowns and the User Journey glossary to map the steps each party takes. The SaaS development overview and CMS vs Custom Development Guide help frame the wider delivery decision.
If you need help defining your first supported transaction, get in touch about marketplace platform development.