The Marketplace Stack
For a services or products marketplace: - Frontend: WeWeb (web) + FlutterFlow (mobile, if needed) - Database: Supabase (PostgreSQL with RLS) - API: Xano (booking logic, availability, search, notifications) - Payments: Stripe Connect (marketplace payouts) - Search: Supabase full-text search or Algolia - Automation: Make (confirmation emails, notifications, dispute workflows)
For a products marketplace, replace Xano with direct Supabase + Stripe APIs if the logic is simple.
The reason we reach for this stack over an all-in-one solution like Sharetribe or Comet is control. With WeWeb + Supabase + Xano, you own the data model completely. You can build any feature a VC-backed marketplace platform offers — custom commission structures, multi-currency, tiered seller verification — without waiting for a vendor to ship it. The tradeoff is build time: expect 3–4 extra weeks compared to a template-based solution. For most serious marketplace businesses, that tradeoff is worth it.
The Database Schema
The core tables for a services marketplace: CREATE TABLE listings ( id bigserial PRIMARY KEY, seller_id uuid REFERENCES auth.users(id), title text, description text, category text, price_cents integer, currency text DEFAULT 'eur', images jsonb, location text, is_active boolean DEFAULT true, created_at timestamptz DEFAULT now() );
CREATE TABLE bookings ( id bigserial PRIMARY KEY, listing_id bigint REFERENCES listings(id), buyer_id uuid, seller_id uuid, status text DEFAULT 'pending', amount_cents integer, stripe_payment_intent_id text, created_at timestamptz DEFAULT now() );
CREATE TABLE reviews ( id bigserial PRIMARY KEY, booking_id bigint REFERENCES bookings(id), reviewer_id uuid, rating integer, body text, created_at timestamptz DEFAULT now() );
Row Level Security is non-negotiable on every table. Buyers must only see their own bookings. Sellers must only see their own listings and incoming bookings. Admins get a service-role key and bypass RLS. Set these policies before you build the frontend — retrofitting RLS into a working app takes twice as long and introduces bugs.
Search and Discovery
For most marketplaces, Supabase full-text search is sufficient at launch. In Xano:
GET /api/listings/search Parameters: query (text), category, min_price, max_price, location Logic: Use Supabase's to_tsvector() full-text search on title + description, combine with category and price filters.
For larger catalogs (10K+ listings) or geo-based search (find providers near me), add Algolia. The WeWeb Algolia plugin makes this connection straightforward.
Search quality is a direct driver of marketplace GMV — buyers who find what they are looking for convert; those who don't, leave. Invest in relevance tuning before launch: add synonym lists, boost recent listings, and surface high-rated sellers for ambiguous queries. Supabase's built-in pg_trgm extension handles fuzzy matching for typos, which is especially important for mobile users who frequently mistype search terms.
Stripe Connect for Marketplace Payments
Marketplace payments use Stripe Connect — sellers have Stripe accounts, buyers pay through your platform, and Stripe handles the split.
Flow: 1. Seller onboards: redirect to Stripe Connect Express onboarding. Store their stripe_account_id in your database. 2. Buyer pays: create a Stripe PaymentIntent with application_fee_amount (your cut). The payment goes to the seller's Stripe account minus your fee. 3. Payout: Stripe automatically pays out to the seller's bank account on a rolling basis.
Implement this in Xano: POST /api/bookings/payment-intent returns the client_secret for the WeWeb payment form.
Application fee structure: most marketplaces charge 10–20% of the transaction value as their platform fee. Stripe deducts this automatically before settling funds to the seller. You receive the fee in your Stripe balance. For regulated industries (financial services, healthcare), consult a payments lawyer before setting your fee structure — some jurisdictions require a payment institution licence if you hold funds for more than 24 hours.
Two-Sided Marketplace Dynamics
Every marketplace faces the cold-start problem: sellers won't join without buyers, and buyers won't come without sellers. The most reliable solution is to seed one side manually before opening the other. At App Studio, we've shipped four marketplaces and the pattern that works is supply-first: recruit 20–30 sellers directly, offer them free or reduced-fee access for the first 3 months, and get listings live before any buyer-facing marketing.
The liquidity threshold — the point at which the marketplace feels usable to buyers — varies by category. For a local services marketplace (cleaners, tutors, handypeople), you need at least 15–20 active listings in each major category before the search experience feels full. For a B2B software marketplace, 30–40 SaaS tools with complete profiles is the minimum. Below the threshold, buyers land on thin search results and leave without converting, poisoning your early data.
Retention on both sides requires separate attention. Sellers churn when bookings dry up; buyers churn when they can't find what they need. Track GMV per seller per week as your leading indicator — a seller going 3+ weeks without a booking is at high churn risk and worth a personal outreach from your team. Automated "boost your listing" nudges in Make can re-engage dormant sellers before they cancel.
Payment Escrow and Stripe Connect Architecture
Full escrow — holding buyer funds until after service delivery — is a major trust driver for high-value or first-time transactions. Stripe Connect supports it natively through the capture_method: manual parameter on PaymentIntents. The buyer's card is authorised at booking time, and you capture the funds only after both parties confirm completion. This gives you 7 days to resolve disputes before money moves.
The Xano workflow for escrow: POST /api/bookings/{id}/complete triggers a Stripe PaymentIntent capture. POST /api/bookings/{id}/dispute sets the booking to a disputed status and pauses the capture. Your admin dashboard then handles the resolution manually. Stripe's dispute API allows you to refund to the buyer or release funds to the seller — build both endpoints in Xano and surface them in your admin UI.
For marketplaces with recurring services (monthly cleaning, weekly tutoring), implement Stripe Subscriptions with a Connect transfer schedule instead of per-booking PaymentIntents. The subscription charges the buyer monthly; a scheduled Make automation triggers a Xano endpoint to split and transfer the seller's portion. This reduces per-transaction API calls and makes your cash flow more predictable.
Trust and Safety Features
A marketplace without trust infrastructure will fail even if the product is technically excellent. Trust features fall into three categories: identity verification, dispute resolution, and community moderation. None of these are optional once you reach meaningful transaction volume — typically around 100 bookings per month.
Identity verification at minimum means verified email and phone number for all users. For higher-trust categories (childcare, home access, financial services), add document verification via a provider like Stripe Identity or Onfido. These services return a verification status you store on the users table and surface as a "Verified" badge on seller profiles. Buyers consistently prefer verified sellers by 2–3x in our client data.
For dispute resolution, build a simple ticket system connected to your bookings table. Each dispute ticket has a status (open, under_review, resolved_buyer, resolved_seller), a message thread between buyer and seller, and an admin override field. Route disputes above a threshold amount (say, €100) to a human review queue. Below that threshold, implement an auto-refund policy — the operational cost of manually reviewing small disputes exceeds the loss from automatic refunds. This policy should be clearly documented in your marketplace terms.
Marketplace SEO
Marketplace SEO is primarily a programmatic content challenge. Your best organic traffic comes from category pages ("yoga teachers in Berlin"), listing pages ("Private Yoga Lessons with Anna K."), and location pages ("services near Prenzlauer Berg"). Each of these needs a unique, indexable URL and enough unique content to pass Google's helpful content threshold.
For category and location pages, generate them programmatically from your Supabase data. A WeWeb page template with a dynamic route (/category/[slug]/[city]) pulls live listing data from Xano and renders it as a static-cacheable HTML response. Add LocalBusiness schema on location pages, ItemList schema on category pages, and Product schema on individual listings. These schema types directly enable rich snippets in Google — star ratings, price ranges, and availability in the search result.
Listing pages with reviews rank significantly better than listings without them. Build a post-booking automated review request into your Make workflow: 24 hours after a booking is marked complete, send the buyer an email with a one-click review link. Even a 20% review completion rate compounds quickly — a marketplace with 500 completed bookings per month will have 1,200 new reviews per year, all adding to the content depth of individual listing pages.
Post-Launch Growth
The first 90 days after launch are the highest-leverage period for a marketplace. Your goal is to reach liquidity — the point at which the marketplace works reliably for buyers without manual intervention from your team. Three levers drive this: supply quality, buyer acquisition, and repeat usage.
Supply quality means curating the seller side ruthlessly in the early days. Reject incomplete listings. Message sellers who haven't responded to a booking within 24 hours. Feature your best sellers on the homepage. Early buyers form their impression of your marketplace from the first 3–5 results they see — if those results are mediocre, they won't return.
Buyer acquisition for a marketplace almost always starts with SEO and paid search, not social media. Intent-based traffic (people searching for exactly what you offer) converts at 5–10x the rate of social traffic. Run Google Ads on your highest-intent category terms from day one and track cost per first booking, not cost per registration. Repeat usage is driven by your post-booking experience: confirmation email, reminder before the service, post-service review request, and a follow-up "Book again" email 30 days later. Build this entire sequence in Make before launch — it is the difference between a one-time transaction platform and a sustainable marketplace business.
Seller Onboarding and Dashboard
Seller experience: 1. Sign up → complete Stripe Connect onboarding 2. Create listings (title, description, images, price, availability) 3. Manage bookings (accept/decline requests, view booking calendar) 4. Track earnings (total paid out, pending payouts, booking history) 5. Manage reviews
All of this is built in WeWeb connected to Xano API endpoints. The seller dashboard typically adds 2–3 weeks to an MVP scope.
The seller dashboard is where marketplace retention is won or lost. Sellers who can clearly see their earnings, upcoming bookings, and review scores stay engaged. Sellers staring at a blank dashboard after a slow week quietly deactivate their listings. Build the earnings section first — it is the most emotionally important metric for sellers and the easiest to make visually compelling. A simple bar chart of weekly earnings in WeWeb using a chart component connected to a Xano aggregation endpoint takes half a day to build and pays dividends in seller retention.
Launch Checklist
Before launching a marketplace: ☑ RLS policies on all tables (buyers can't see other buyers' private data, sellers can't see each other's stripe_account_id) ☑ Stripe webhook handler for payment events (confirmation, disputes, refunds) ☑ Email notifications for all booking state changes (Make automation) ☑ Admin dashboard for dispute resolution ☑ Terms of service and marketplace policies ☑ Load test with 100 concurrent users before launch
A common mistake: launching without the admin dashboard. Within the first week of a live marketplace, you will need to manually resolve a booking dispute. Build the admin tools before you go live.
Additionally: test the full buyer-to-payout cycle with a real transaction before launch — charge a real card, complete the booking, trigger a payout to a test Stripe Connect account, and verify the funds arrive. Stripe's sandbox mode is excellent but it cannot catch every edge case in your Xano logic. A €1 test transaction caught a webhook timing bug on one of our marketplace launches that would have caused double-charging at scale. That 10-minute test saved a catastrophic production incident.