Der Marktplatz-Stack

Für einen Dienstleistungs- oder Produktmarktplatz: - Frontend: WeWeb (Web) + FlutterFlow (Mobil, bei Bedarf) - Datenbank: Supabase (PostgreSQL mit RLS) - API: Xano (Buchungslogik, Verfügbarkeit, Suche, Benachrichtigungen) - Zahlungen: Stripe Connect (Marktplatz-Auszahlungen) - Suche: Supabase Volltext-Suche oder Algolia - Automatisierung: Make (Bestätigungs-E-Mails, Benachrichtigungen, Streitfall-Flows)

Für einen Produktmarktplatz kannst du Xano durch direkte Supabase- und Stripe-APIs ersetzen, wenn die Logik einfach ist.

Der Grund, warum wir bei diesem Stack bleiben statt eine All-in-One-Lösung wie Sharetribe oder Comet zu nutzen, ist Kontrolle. Mit WeWeb + Supabase + Xano besitzt du das Datenmodell vollständig. Du kannst jede Funktion bauen, die eine VC-finanzierte Marktplatz-Plattform bietet, individuelle Provisionsstrukturen, Mehrwährungsfähigkeit, gestufte Verkäuferverifizierung, ohne darauf zu warten, dass ein Anbieter sie liefert. Der Kompromiss ist die Bauzeit: Rechne mit 3-4 zusätzlichen Wochen im Vergleich zu einer templatebasierten Lösung. Für die meisten ernsthaften Marktplatz-Unternehmen lohnt sich dieser Kompromiss.

Für einen deutschen Marktplatz solltest du außerdem Klarna Checkout oder SEPA-Lastschrift über Stripe für verbraucherfreundliche Zahlungen integrieren, in Deutschland sind beide Zahlungsmethoden Standard und erhöhen die Conversion gegenüber reiner Kreditkartenzahlung erheblich.

Das Datenbankschema

Kerntabellen für einen Dienstleistungsmarktplatz:

listings-Tabelle: id, seller_id, title, description, category, price_cents, currency (Standard 'eur' für Deutschland), images, location, is_active, created_at.

bookings-Tabelle: id, listing_id, buyer_id, seller_id, status (pending/accepted/completed/disputed), amount_cents, stripe_payment_intent_id, created_at.

reviews-Tabelle: id, booking_id, reviewer_id, rating, body, created_at.

Row Level Security ist auf jeder Tabelle nicht verhandelbar. Käufer dürfen ausschließlich ihre eigenen Buchungen sehen. Verkäufer dürfen ausschließlich ihre eigenen Listings und eingehenden Buchungen sehen. Admins erhalten einen Service-Role-Key und umgehen RLS. Lege diese Richtlinien fest, bevor du das Frontend baust, RLS nachträglich in eine bereits laufende App einzubauen dauert doppelt so lange und führt zu Fehlern.

Für einen deutschen Marktplatz füge immer ein consent_dsgvo-Feld und einen data_processing_accepted_at-Timestamp zur users-Tabelle hinzu. Das ist eine Anforderung für DSGVO-Konformität und erleichtert Audits durch Datenschutzbehörden.

Suche und Discovery

Für die meisten Marktplätze ist Supabase Volltext-Suche beim Launch ausreichend. In Xano:

GET /api/listings/search Parameter: query (Text), category, min_price, max_price, location Logik: Supabase to_tsvector() Volltext-Suche auf title + description verwenden, mit Kategorie- und Preisfiltern kombinieren.

Für größere Kataloge (10.000+ Listings) oder geo-basierte Suche (Anbieter in meiner Nähe finden) füge Algolia hinzu. Das WeWeb Algolia-Plugin macht die Verbindung einfach.

Suchqualität ist ein direkter Treiber für den GMV eines Marktplatzes, Käufer, die finden, wonach sie suchen, konvertieren, wer nicht fündig wird, springt ab. Investiere vor dem Launch in Relevanz-Tuning: Füge Synonymlisten hinzu, bevorzuge aktuelle Listings und zeige bei mehrdeutigen Suchanfragen bevorzugt hochbewertete Verkäufer an. Die integrierte pg_trgm-Erweiterung von Supabase übernimmt Fuzzy-Matching bei Tippfehlern, was besonders für mobile Nutzer wichtig ist, die Suchbegriffe häufig falsch eingeben.

Für deutsche Marktplätze mit geografischer Suche (Anbieter in meiner Nähe finden) empfehlen wir die PostGIS-Erweiterung in Supabase für geo-koordinatenbasierte Suchen. Das ist entscheidend für Dienstleistungsmarktplätze in den Bereichen Handwerk, Reinigung und Transport, typische Anwendungsfälle im deutschen Mittelstandssegment.

Stripe Connect für Marktplatz-Zahlungen

Marktplatz-Zahlungen verwenden Stripe Connect, Verkäufer haben Stripe-Konten, Käufer zahlen über deine Plattform und Stripe übernimmt die Aufteilung.

Flow: 1. Verkäufer onboardet: Weiterleitung zum Stripe Connect Express-Onboarding. Seine stripe_account_id in deiner Datenbank speichern. 2. Käufer zahlt: Stripe PaymentIntent mit application_fee_amount (deine Gebühr) erstellen. Die Zahlung geht an das Stripe-Konto des Verkäufers abzüglich deiner Gebühr. 3. Auszahlung: Stripe zahlt automatisch auf das Bankkonto des Verkäufers aus.

Dies in Xano implementieren: POST /api/bookings/payment-intent gibt client_secret für das WeWeb-Zahlungsformular zurück. Stripe unterstützt EUR-Transaktionen und ist von der BaFin zugelassen.

Struktur der Anwendungsgebühr: Die meisten Marktplätze berechnen 10-20% des Transaktionswerts als Plattformgebühr. Stripe zieht diese automatisch ab, bevor die Gelder an den Verkäufer ausgezahlt werden. Du erhältst die Gebühr in deinem Stripe-Guthaben. Für regulierte Branchen (Finanzdienstleistungen, Gesundheitswesen) solltest du vor der Festlegung deiner Gebührenstruktur einen Zahlungsrechtsexperten konsultieren, manche Rechtsordnungen verlangen eine Zahlungsinstitutslizenz, wenn du Gelder länger als 24 Stunden hältst.

Dynamiken eines zweiseitigen Marktplatzes

Jeder Marktplatz steht vor dem Cold-Start-Problem: Verkäufer treten nicht bei, ohne Käufer, und Käufer kommen nicht, ohne Verkäufer. Die zuverlässigste Lösung ist, eine Seite manuell aufzubauen, bevor du die andere öffnest. Bei App Studio haben wir vier Marktplätze auf den Markt gebracht, und das Muster, das funktioniert, ist supply-first: Rekrutiere 20-30 Verkäufer direkt, biete ihnen für die ersten 3 Monate kostenlosen oder gebührenreduzierten Zugang und bringe Listings live, bevor überhaupt käuferseitiges Marketing beginnt.

Die Liquiditätsschwelle, der Punkt, an dem sich der Marktplatz für Käufer nutzbar anfühlt, variiert je nach Kategorie. Für einen lokalen Dienstleistungsmarktplatz (Reinigungskräfte, Nachhilfelehrer, Handwerker) brauchst du mindestens 15-20 aktive Listings in jeder Hauptkategorie, bevor sich die Sucherfahrung vollständig anfühlt. Für einen B2B-Software-Marktplatz sind 30-40 SaaS-Tools mit vollständigen Profilen das Minimum. Unterhalb dieser Schwelle landen Käufer bei dürftigen Suchergebnissen und verlassen die Seite, ohne zu konvertieren, was deine frühen Daten verzerrt.

Retention auf beiden Seiten erfordert getrennte Aufmerksamkeit. Verkäufer wandern ab, wenn Buchungen ausbleiben, Käufer wandern ab, wenn sie nicht finden, was sie brauchen. Verfolge GMV pro Verkäufer pro Woche als Frühindikator, ein Verkäufer, der 3+ Wochen ohne Buchung bleibt, hat ein hohes Abwanderungsrisiko und ist eine persönliche Kontaktaufnahme durch dein Team wert. Automatisierte "Pushe dein Listing"-Erinnerungen in Make können inaktive Verkäufer reaktivieren, bevor sie kündigen.

Zahlungs-Treuhand und Stripe-Connect-Architektur

Vollständige Treuhand (Escrow), bei der Käufergelder bis nach der Leistungserbringung einbehalten werden, ist ein wichtiger Vertrauenstreiber bei hochpreisigen oder erstmaligen Transaktionen. Stripe Connect unterstützt dies nativ über den Parameter capture_method: manual bei PaymentIntents. Die Karte des Käufers wird zum Buchungszeitpunkt autorisiert, und du erfasst die Gelder erst, nachdem beide Parteien den Abschluss bestätigt haben. Das gibt dir 7 Tage, um Streitfälle zu klären, bevor Geld bewegt wird.

Der Xano-Workflow für Escrow: POST /api/bookings/{id}/complete löst eine Stripe-PaymentIntent-Erfassung aus. POST /api/bookings/{id}/dispute setzt die Buchung auf den Status "disputed" und pausiert die Erfassung. Dein Admin-Dashboard übernimmt dann die Lösung manuell. Die Dispute-API von Stripe erlaubt es dir, an den Käufer zu erstatten oder die Gelder an den Verkäufer freizugeben, baue beide Endpoints in Xano und zeige sie in deiner Admin-Oberfläche an.

Für Marktplätze mit wiederkehrenden Dienstleistungen (monatliche Reinigung, wöchentliche Nachhilfe) implementiere Stripe Subscriptions mit einem Connect-Transfer-Zeitplan statt PaymentIntents pro Buchung. Das Abonnement belastet den Käufer monatlich, eine geplante Make-Automatisierung löst einen Xano-Endpoint aus, um den Anteil des Verkäufers aufzuteilen und zu überweisen. Das reduziert die Anzahl der API-Aufrufe pro Transaktion und macht deinen Cashflow planbarer.

Vertrauen und Sicherheit

Ein Marktplatz ohne Vertrauensinfrastruktur scheitert, selbst wenn das Produkt technisch exzellent ist. Vertrauensfunktionen fallen in drei Kategorien: Identitätsverifizierung, Streitfallauflösung und Community-Moderation. Keine davon ist optional, sobald du ein relevantes Transaktionsvolumen erreichst, typischerweise etwa 100 Buchungen pro Monat.

Identitätsverifizierung bedeutet im Minimum verifizierte E-Mail-Adresse und Telefonnummer für alle Nutzer. Für Kategorien mit höherem Vertrauensbedarf (Kinderbetreuung, Zugang zum eigenen Zuhause, Finanzdienstleistungen) füge Dokumentenverifizierung über einen Anbieter wie Stripe Identity oder Onfido hinzu. Diese Dienste liefern einen Verifizierungsstatus, den du in der users-Tabelle speicherst und als "Verifiziert"-Badge auf Verkäuferprofilen anzeigst. Käufer bevorzugen verifizierte Verkäufer in unseren Kundendaten durchgängig um das 2-3-fache.

Für die Streitfallauflösung baue ein einfaches Ticket-System, das mit deiner bookings-Tabelle verbunden ist. Jedes Streitfall-Ticket hat einen Status (open, under_review, resolved_buyer, resolved_seller), einen Nachrichtenverlauf zwischen Käufer und Verkäufer sowie ein Admin-Override-Feld. Leite Streitfälle oberhalb eines Schwellenwerts (zum Beispiel 100 €) an eine manuelle Prüfwarteschlange weiter. Unterhalb dieser Schwelle implementiere eine automatische Erstattungsrichtlinie, die operativen Kosten für die manuelle Prüfung kleiner Streitfälle übersteigen den Verlust durch automatische Erstattungen. Diese Richtlinie sollte klar in deinen Marktplatz-AGB dokumentiert sein.

SEO für Marktplätze

SEO für Marktplätze ist in erster Linie eine programmatische Content-Herausforderung. Dein bester organischer Traffic kommt von Kategorieseiten ("Yogalehrer in Berlin"), Listing-Seiten ("Private Yogastunden mit Anna K.") und Standortseiten ("Dienstleistungen in der Nähe von Prenzlauer Berg"). Jede dieser Seiten braucht eine eindeutige, indexierbare URL und genug einzigartigen Content, um Googles Schwelle für hilfreichen Content zu erreichen.

Für Kategorie- und Standortseiten generierst du diese programmatisch aus deinen Supabase-Daten. Eine WeWeb-Seitenvorlage mit einer dynamischen Route (/category/[slug]/[city]) zieht Live-Listing-Daten aus Xano und rendert sie als statisch cachebare HTML-Antwort. Füge LocalBusiness-Schema auf Standortseiten, ItemList-Schema auf Kategorieseiten und Product-Schema auf einzelnen Listings hinzu. Diese Schema-Typen ermöglichen direkt Rich Snippets bei Google, Sternebewertungen, Preisspannen und Verfügbarkeit im Suchergebnis.

Listing-Seiten mit Bewertungen ranken deutlich besser als Listings ohne. Baue eine automatisierte Bewertungsanfrage nach der Buchung in deinen Make-Workflow ein: 24 Stunden nachdem eine Buchung als abgeschlossen markiert wurde, sende dem Käufer eine E-Mail mit einem Ein-Klick-Bewertungslink. Selbst eine Abschlussrate von 20% bei Bewertungen summiert sich schnell, ein Marktplatz mit 500 abgeschlossenen Buchungen pro Monat erhält 1.200 neue Bewertungen pro Jahr, die alle zur Content-Tiefe der einzelnen Listing-Seiten beitragen.

Wachstum nach dem Launch

Die ersten 90 Tage nach dem Launch sind die Phase mit dem größten Hebel für einen Marktplatz. Dein Ziel ist es, Liquidität zu erreichen, den Punkt, an dem der Marktplatz für Käufer zuverlässig funktioniert, ohne manuelles Eingreifen deines Teams. Drei Hebel treiben das an: Angebotsqualität, Käufergewinnung und wiederkehrende Nutzung.

Angebotsqualität bedeutet, die Verkäuferseite in den frühen Tagen konsequent zu kuratieren. Lehne unvollständige Listings ab. Kontaktiere Verkäufer, die nicht innerhalb von 24 Stunden auf eine Buchung reagiert haben. Stelle deine besten Verkäufer auf der Startseite vor. Frühe Käufer bilden sich ihren Eindruck von deinem Marktplatz anhand der ersten 3-5 Ergebnisse, die sie sehen, wenn diese mittelmäßig sind, kommen sie nicht zurück.

Käufergewinnung für einen Marktplatz beginnt fast immer mit SEO und bezahlter Suche, nicht mit Social Media. Intent-basierter Traffic (Menschen, die genau nach dem suchen, was du anbietest) konvertiert 5-10x besser als Social-Traffic. Schalte von Tag eins an Google Ads auf deine Kategoriebegriffe mit der höchsten Kaufabsicht und verfolge die Kosten pro erster Buchung, nicht die Kosten pro Registrierung. Wiederkehrende Nutzung wird durch dein Post-Booking-Erlebnis angetrieben: Bestätigungs-E-Mail, Erinnerung vor der Leistung, Bewertungsanfrage nach der Leistung und eine Follow-up-E-Mail "Jetzt erneut buchen" 30 Tage später. Baue diese gesamte Sequenz vor dem Launch in Make, sie macht den Unterschied zwischen einer einmaligen Transaktionsplattform und einem nachhaltigen Marktplatz-Geschäft.

Verkäufer-Onboarding und Dashboard

Verkäufererfahrung: 1. Registrierung → Stripe Connect-Onboarding abschließen 2. Listings erstellen (Titel, Beschreibung, Bilder, Preis, Verfügbarkeit) 3. Buchungen verwalten (Anfragen annehmen/ablehnen, Buchungskalender anzeigen) 4. Einnahmen verfolgen (gesamte Auszahlungen, ausstehende Auszahlungen, Buchungshistorie) 5. Bewertungen verwalten

Alles wird in WeWeb gebaut, verbunden mit Xano-API-Endpoints. Das Verkäufer-Dashboard fügt normalerweise 2-3 Wochen zum MVP-Scope hinzu.

Das Verkäufer-Dashboard entscheidet darüber, ob die Retention im Marktplatz gewonnen oder verloren wird. Verkäufer, die ihre Einnahmen, anstehenden Buchungen und Bewertungen klar sehen können, bleiben engagiert. Verkäufer, die nach einer schwachen Woche auf ein leeres Dashboard starren, deaktivieren ihre Listings still und leise. Baue zuerst den Einnahmenbereich, er ist die emotional wichtigste Kennzahl für Verkäufer und am einfachsten visuell überzeugend zu gestalten. Ein einfaches Balkendiagramm der wöchentlichen Einnahmen in WeWeb mit einer Chart-Komponente, verbunden mit einem Xano-Aggregations-Endpoint, dauert einen halben Tag zu bauen und zahlt sich in der Verkäufer-Retention aus.

Launch-Checkliste

Vor dem Launch eines Marktplatzes: ☑ RLS-Richtlinien für alle Tabellen (Käufer können keine privaten Daten anderer Käufer sehen, Verkäufer können nicht die stripe_account_id der jeweils anderen einsehen) ☑ Stripe-Webhook-Handler für Zahlungsereignisse (Bestätigung, Streitfälle, Erstattungen) ☑ E-Mail-Benachrichtigungen für alle Buchungsstatusänderungen (Make-Automatisierung) ☑ Admin-Dashboard für Streitfallauflösung ☑ AGB, Datenschutzerklärung, DSGVO-Einwilligung und Impressum (Pflicht in Deutschland) ☑ Barrierefreiheitstest (WCAG 2.1 AA), immer mehr deutsche Ausschreibungen erfordern dies ☑ Lasttest mit 100 gleichzeitigen Nutzern vor dem Launch

Ein häufiger Fehler: der Launch ohne Admin-Dashboard. Innerhalb der ersten Woche eines lebenden Marktplatzes wirst du eine Buchungsstreitigkeit manuell lösen müssen. Baue die Admin-Tools, bevor du live gehst.

Zusätzlich: Teste den gesamten Zyklus von Käufer bis Auszahlung mit einer echten Transaktion vor dem Launch, belaste eine echte Karte, schließe die Buchung ab, löse eine Auszahlung an ein Test-Stripe-Connect-Konto aus und verifiziere, dass die Gelder ankommen. Der Sandbox-Modus von Stripe ist exzellent, kann aber nicht jeden Grenzfall in deiner Xano-Logik abfangen. Eine Testtransaktion über 1 € hat bei einem unserer Marktplatz-Launches einen Timing-Fehler im Webhook aufgedeckt, der bei Skalierung zu Doppelbelastungen geführt hätte. Dieser 10-minütige Test hat einen katastrophalen Produktionsvorfall verhindert.

App Studio hat über 50 Apps in Produktion geliefert, darunter mehrere Marktplätze. Wir helfen dir, in 8-12 Wochen live zu gehen. Kontaktiere uns auf /contact.