One platform for the entire creative transaction — from discovery to payout.

Marketplace data leaks kill trust. When a creator can see another creator's earnings, or a client's conversation leaks to the wrong user, the platform is dead. The challenge isn't building two interfaces — it's ensuring they share a transactional layer (bookings, payments, messaging) without leaking data across role boundaries.

This is enforced at the database level with row-level security policies scoped per role. Creators can only see their own bookings and earnings. Clients can only access their own orders and conversations. Admin operations use a separate service role with elevated permissions, verified on every request. Even a compromised API layer can't leak data across users.

The platform also maintains a deliberate separation between auth provider IDs and application user IDs via a mapping column. Messaging, bookings, and payments all reference the application user ID — not the auth provider's UID. This means the entire authentication provider could be swapped out without migrating a single row in the core business tables.

Both sides share a unified booking engine, real-time messaging, and notification layer — built once, with access controlled by RLS rather than duplicated application logic.

A broken booking means a creator doesn't get paid and a client doesn't get the service they need. The system handles two fundamentally different booking types — services and spaces — through a unified architecture, because splitting them would mean splitting every downstream system too.

Service bookings follow a structured lifecycle:

1. Request — the client submits a booking request with date, time, and details
2. Review — the creator receives the request and can accept or reject it from their dashboard
3. Payment — on acceptance, the client is prompted to pay via Stripe
4. Completion — after the service is delivered, the booking is marked complete and the client can leave a review
5. Dispute — if something goes wrong, either party can raise a dispute, triggering multi-channel admin notification with graceful degradation — if the email fails, the dispute is still created and the in-app notification still fires

Space bookings support two distinct pricing models — hourly and daily — enforced at the database level with PostgreSQL CHECK constraints. If a booking is hourly, start and end times are required; if daily, a daily rate and date range are required. Duration fields are generated columns, computed automatically from the date range. Invalid booking states can't exist in the database, regardless of what the application code does.

Reviews are locked to completed bookings — you can only review a creator after a real, paid transaction. This eliminates fake reviews, competitor sabotage, and reputation gaming at the database level.

If creators don't get paid quickly and transparently, they leave. Handling money in a marketplace is fundamentally different from processing a simple checkout — the platform doesn't just collect payments, it splits them, routing funds to creators while retaining a platform commission.

This is built on Stripe Connect with a managed account model:

1. Creator onboarding — creators connect their Stripe account through an OAuth flow directly from their dashboard. The platform handles identity verification and payout setup without the creator needing to manage Stripe independently.
2. Payment intent creation — when a booking is confirmed, a Stripe payment intent is created with the platform's 2% fee built in. The remaining 98% is routed directly to the creator's connected account.
3. Webhook-driven state management — payment events (success, failure, refund) are processed through Stripe webhooks, keeping booking state in sync with payment state at all times.
4. Full audit schema — payment intents tracked across eight statuses, a transactions table recording completed payments with fee breakdowns, and a separate refunds table for refund history — giving both the platform and creators complete financial visibility.

Discovery is the lifeblood of a marketplace. If clients can't find the right creator quickly, nothing else matters.

The search system runs entirely at the database level using PostgreSQL's native full-text search. A trigger builds search indexes dynamically whenever a service is created or updated, combining core service fields, creator information, and the full category hierarchy — resolved via a recursive query that walks from the service's category up through every parent category.

This means a search for “video” will surface services categorised under “music video,” “corporate video,” or any other subcategory in the hierarchy — without the application needing to know the category tree at query time.

Search results are ranked using PostgreSQL's built-in relevance scoring. On top of this, a dedicated search suggestions function powers the search bar's autocomplete with three-tiered results: Categories → Services → Creators, each with independent relevance scoring and dynamic result limits. The entire search pipeline — indexing, ranking, and suggestions — runs in the database, not in application code.

A booking request that sits unseen for hours is a booking that never happens. In a marketplace where bookings require back-and-forth between creators and clients, delayed notifications mean lost revenue. The platform uses Supabase's realtime channel subscriptions to push notifications instantly via PostgreSQL's change data capture — no polling, no external pub/sub service.

When a row is inserted into the notifications table — a new booking request, a payment confirmation, an accepted booking — the client receives it immediately through an open WebSocket connection. Notification types carry structured metadata (booking ID, amount, checkout URL) so the frontend can render contextual actions without additional API calls.

The notification provider includes in-flight fetch protection using React refs to prevent duplicate requests during rapid state changes, and computes unread counts locally from the notification array rather than making separate count queries.

The built-in messaging system keeps all communication — from initial enquiry to post-booking follow-up — in one auditable place, with unread counts surfaced in the navigation bar and threaded conversations with full history.

A duplicated webhook means a creator gets paid twice. A dropped one means they don't get paid at all. Payment webhooks are inherently unreliable — Stripe may send the same event multiple times, network failures cause retries, and out-of-order delivery is common. In a marketplace handling real money between two parties, every edge case is a financial risk.

The platform handles this with a dedicated webhook events table that logs every incoming webhook with its Stripe event ID, event type, and a processed flag. A unique constraint on the event ID means duplicate deliveries are silently ignored via the database, not application logic.

Events are marked as processed only after the associated database operations (booking status update, transaction record creation) complete successfully. If processing fails, the event remains unprocessed with the error recorded alongside it — making failed webhooks visible and replayable without re-triggering them from Stripe.

The webhook endpoint preserves the raw request body as text rather than parsing it as JSON for Stripe's signature verification — a subtle but critical detail, since JSON parsing and re-serialisation can alter whitespace and break the HMAC check.