Hur du bygger en tvåsidig marknadsplats med no-code 2025

Marknadsplatsens stack

För en tjänste- eller produktmarknadsplats: - Frontend: WeWeb (webb) + FlutterFlow (mobil, vid behov) - Databas: Supabase (PostgreSQL med RLS) - API: Xano (bokningslogik, tillgänglighet, sökning, aviseringar) - Betalningar: Stripe Connect (marknadsplatsutbetalningar) - Sökning: Supabase fulltext-sökning eller Algolia - Automatisering: Make (bekräftelsemejl, aviseringar, tvistflöden)

För en produktmarknadsplats, ersätt Xano med direkta Supabase- och Stripe-API:er om logiken är enkel. För en svensk marknadsplats bör du dessutom överväga att integrera Klarna Checkout för konsumentvänliga betalningar, Klarna är standard på den svenska marknaden och ökar konverteringen markant jämfört med ren kortbetalning.

Anledningen till att vi väljer den här stacken framför en helhetslösning som Sharetribe eller Comet är kontroll. Med WeWeb, Supabase och Xano äger du datamodellen helt och hållet. Du kan bygga alla funktioner som en VC-finansierad marknadsplatsplattform erbjuder, anpassade provisionsstrukturer, flervaluta, nivåindelad säljarverifiering, utan att vänta på att en leverantör ska leverera det. Avvägningen är byggtid: räkna med 3-4 extra veckor jämfört med en mallbaserad lösning. För de flesta seriösa marknadsplatsverksamheter är den avvägningen värd det.

Databasschemat

Kärntabellerna för en tjänstemarknadsplats:

listings-tabellen: id, seller_id, title, description, category, price_cents, currency (standard 'sek' för Sverige), images, location, is_active, created_at.

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

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

Row Level Security är inte förhandlingsbart på någon tabell. Köpare får bara se sina egna bokningar. Säljare får bara se sina egna listor och inkommande bokningar. Administratörer får en service-role-nyckel och kringgår RLS. Sätt dessa policyer innan du bygger frontend, att i efterhand lägga till RLS i en fungerande app tar dubbelt så lång tid och introducerar buggar.

För en svensk marknadsplats, lägg alltid till ett consent_gdpr-fält och en data_processing_accepted_at-timestamp på users-tabellen. Det är ett krav för GDPR-efterlevnad och underlättar revisioner.

Sökning och discovery

För de flesta marknadsplatser är Supabase fulltext-sökning tillräcklig vid lansering. I Xano:

GET /api/listings/search Parametrar: query (text), category, min_price, max_price, location Logik: Använd Supabase to_tsvector() fulltext-sökning på title + description, kombinera med kategori- och prisfilter.

För större kataloger (10 000+ listor) eller geobaserad sökning (hitta leverantörer nära mig) lägg till Algolia. WeWeb Algolia-plugin gör kopplingen enkel.

Sökkvalitet är en direkt drivkraft för marknadsplatsens GMV, köpare som hittar det de letar efter konverterar; de som inte gör det lämnar. Investera i relevansjustering innan lansering: lägg till synonymlistor, boosta nya listningar och lyft fram högt rankade säljare för tvetydiga sökningar. Supabases inbyggda pg_trgm-tillägg hanterar fuzzy matching för stavfel, vilket är särskilt viktigt för mobilanvändare som ofta felstavar söktermer.

För svenska marknadsplatser med geografisk sökning rekommenderar vi dessutom PostGIS-tillägget i Supabase för geo-koordinatbaserade sökningar. Det är kritiskt för tjänstemarknadsplatser inom städning, hantverk och transport.

Stripe Connect för marknadsplatsbetalningar

Marknadsplatsbetalningar använder Stripe Connect, säljare har Stripe-konton, köpare betalar via din plattform och Stripe hanterar uppdelningen.

Flöde: 1. Säljare onboardar: omdirigera till Stripe Connect Express-onboarding. Lagra deras stripe_account_id i din databas. 2. Köpare betalar: skapa ett Stripe PaymentIntent med application_fee_amount (din avgift). Betalningen går till säljarens Stripe-konto minus din avgift. 3. Utbetalning: Stripe betalar automatiskt ut till säljarens bankkonto löpande.

Implementera detta i Xano: POST /api/bookings/payment-intent returnerar client_secret för WeWeb-betalningsformuläret. Stripe stöder SEK-transaktioner och är godkänt av Finansinspektionen.

Avgiftsstruktur: de flesta marknadsplatser tar 10-20% av transaktionsvärdet som sin plattformsavgift. Stripe drar av detta automatiskt innan medlen regleras till säljaren. Du får avgiften på ditt Stripe-saldo. För reglerade branscher (finansiella tjänster, sjukvård), konsultera en betalningsjurist innan du sätter din avgiftsstruktur, vissa jurisdiktioner kräver ett betalinstitutstillstånd om du håller medel längre än 24 timmar.

Tvåsidig marknadsplatsdynamik

Varje marknadsplats möter kallstartsproblemet: säljare vill inte gå med utan köpare, och köpare kommer inte utan säljare. Den mest pålitliga lösningen är att så en sida manuellt innan du öppnar den andra. På App Studio har vi levererat fyra marknadsplatser och mönstret som fungerar är utbudsförst: rekrytera 20-30 säljare direkt, erbjud dem gratis eller reducerad avgift de första 3 månaderna, och få listor live innan någon köparriktad marknadsföring.

Likviditetströskeln, punkten där marknadsplatsen känns användbar för köpare, varierar per kategori. För en lokal tjänstemarknadsplats (städare, handledare, hantverkare) behöver du minst 15-20 aktiva listor i varje huvudkategori innan sökupplevelsen känns fullständig. För en B2B-mjukvarumarknadsplats är 30-40 SaaS-verktyg med kompletta profiler minimum. Under tröskeln landar köpare på tunna sökresultat och lämnar utan att konvertera, vilket förgiftar din tidiga data.

Retention på båda sidor kräver separat uppmärksamhet. Säljare tappar intresse när bokningarna sinar; köpare tappar intresse när de inte hittar vad de behöver. Spåra GMV per säljare per vecka som din ledande indikator, en säljare som går 3+ veckor utan en bokning löper hög risk att lämna och är värd personlig uppföljning från ditt team. Automatiserade "boosta din annons"-påminnelser i Make kan återengagera slumrande säljare innan de avslutar sitt konto.

Betalningsescrow och Stripe Connect-arkitektur

Full escrow, att hålla köparens pengar tills efter tjänsteleverans, är en viktig förtroendedrivare för högvärdes- eller förstagångstransaktioner. Stripe Connect stöder detta nativt genom parametern capture_method: manual på PaymentIntents. Köparens kort auktoriseras vid bokningstillfället, och du fångar (capture) medlen först efter att båda parter bekräftar att jobbet är klart. Detta ger dig 7 dagar att lösa tvister innan pengarna flyttas.

Xano-arbetsflödet för escrow: POST /api/bookings/{id}/complete utlöser en Stripe PaymentIntent-capture. POST /api/bookings/{id}/dispute sätter bokningen till en tvistestatus och pausar capture. Din admin-dashboard hanterar sedan lösningen manuellt. Stripes tviste-API låter dig återbetala köparen eller frisläppa medel till säljaren, bygg båda endpoints i Xano och visa dem i ditt admin-gränssnitt.

För marknadsplatser med återkommande tjänster (månatlig städning, veckovis handledning), implementera Stripe Subscriptions med ett Connect-överföringsschema istället för PaymentIntents per bokning. Prenumerationen debiterar köparen månadsvis; en schemalagd Make-automatisering utlöser en Xano-endpoint som delar upp och överför säljarens andel. Detta minskar antalet API-anrop per transaktion och gör ditt kassaflöde mer förutsägbart.

Förtroende- och säkerhetsfunktioner

En marknadsplats utan förtroendeinfrastruktur kommer misslyckas även om produkten är tekniskt utmärkt. Förtroendefunktioner delas in i tre kategorier: identitetsverifiering, tvistlösning och communitymoderering. Ingen av dessa är valfri när du når meningsfull transaktionsvolym, typiskt runt 100 bokningar per månad.

Identitetsverifiering betyder som minimum verifierad e-post och telefonnummer för alla användare. För kategorier med högre förtroendekrav (barnpassning, hemtillträde, finansiella tjänster), lägg till dokumentverifiering via en leverantör som Stripe Identity eller Onfido. Dessa tjänster returnerar en verifieringsstatus som du lagrar på users-tabellen och visar som en "Verifierad"-badge på säljarprofiler. Köpare föredrar konsekvent verifierade säljare med 2-3x i vår klientdata.

För tvistlösning, bygg ett enkelt ärendesystem kopplat till din bookings-tabell. Varje tvistärende har en status (open, under_review, resolved_buyer, resolved_seller), en meddelandetråd mellan köpare och säljare, och ett admin-överstyrningsfält. Dirigera tvister över ett tröskelbelopp (säg 100 euro) till en mänsklig granskningskö. Under den tröskeln, implementera en policy för automatisk återbetalning, den operativa kostnaden för att manuellt granska små tvister överstiger förlusten från automatiska återbetalningar. Denna policy bör tydligt dokumenteras i dina marknadsplatsvillkor.

Marknadsplats-SEO

Marknadsplats-SEO är primärt en programmatisk innehållsutmaning. Din bästa organiska trafik kommer från kategorisidor ("yogalärare i Berlin"), listningssidor ("Privata yogalektioner med Anna K.") och platssidor ("tjänster nära Prenzlauer Berg"). Var och en av dessa behöver en unik, indexerbar URL och tillräckligt med unikt innehåll för att klara Googles tröskel för hjälpsamt innehåll.

För kategori- och platssidor, generera dem programmatiskt från din Supabase-data. En WeWeb-sidmall med en dynamisk rutt (/category/[slug]/[city]) hämtar levande listningsdata från Xano och renderar den som ett statiskt cachebart HTML-svar. Lägg till LocalBusiness-schema på platssidor, ItemList-schema på kategorisidor och Product-schema på enskilda listningar. Dessa schematyper möjliggör direkt rika sökresultat i Google, stjärnbetyg, prisintervall och tillgänglighet i sökresultatet.

Listningssidor med recensioner rankar betydligt bättre än listningar utan dem. Bygg en automatiserad recensionsförfrågan efter bokning i ditt Make-arbetsflöde: 24 timmar efter att en bokning markerats klar, skicka köparen ett mejl med en recensionslänk i ett klick. Även en 20% svarsfrekvens på recensioner ger snabbt effekt, en marknadsplats med 500 avslutade bokningar per månad kommer få 1 200 nya recensioner per år, vilket alla bidrar till innehållsdjupet på enskilda listningssidor.

Tillväxt efter lansering

De första 90 dagarna efter lansering är den period som ger störst hävstång för en marknadsplats. Ditt mål är att nå likviditet, punkten där marknadsplatsen fungerar pålitligt för köpare utan manuell inblandning från ditt team. Tre spakar driver detta: utbudskvalitet, köparförvärv och återkommande användning.

Utbudskvalitet betyder att du kurerar säljarsidan hänsynslöst under de tidiga dagarna. Avvisa ofullständiga listningar. Skicka meddelande till säljare som inte svarat på en bokning inom 24 timmar. Lyft fram dina bästa säljare på startsidan. Tidiga köpare bildar sitt intryck av din marknadsplats från de första 3-5 resultaten de ser, om de resultaten är medelmåttiga kommer de inte tillbaka.

Köparförvärv för en marknadsplats börjar nästan alltid med SEO och betald sökning, inte sociala medier. Intentionsbaserad trafik (personer som söker exakt det du erbjuder) konverterar 5-10x bättre än trafik från sociala medier. Kör Google Ads på dina kategoritermer med högst köpintention från dag ett och spåra kostnad per första bokning, inte kostnad per registrering. Återkommande användning drivs av din upplevelse efter bokning: bekräftelsemejl, påminnelse innan tjänsten, recensionsförfrågan efter tjänsten, och ett uppföljande "boka igen"-mejl 30 dagar senare. Bygg hela denna sekvens i Make innan lansering, det är skillnaden mellan en engångstransaktionsplattform och en hållbar marknadsplatsverksamhet.

Säljares onboarding och dashboard

Säljarupplevelse: 1. Registrering → slutför Stripe Connect-onboarding 2. Skapa listor (titel, beskrivning, bilder, pris, tillgänglighet) 3. Hantera bokningar (acceptera/avvisa förfrågningar, visa bokningskalender) 4. Spåra intäkter (totalt utbetalt, väntande utbetalningar, bokningshistorik) 5. Hantera recensioner

Allt detta byggs i WeWeb kopplat till Xano API-endpoints. Säljar-dashboarden lägger vanligtvis till 2-3 veckor till en MVP-scope.

Säljar-dashboarden är där marknadsplatsens retention vinns eller förloras. Säljare som tydligt kan se sina intäkter, kommande bokningar och recensionspoäng förblir engagerade. Säljare som stirrar på en tom dashboard efter en dålig vecka avaktiverar tyst sina listor. Bygg intäktssektionen först, det är den känslomässigt viktigaste mätaren för säljare och den enklaste att göra visuellt övertygande. Ett enkelt stapeldiagram över veckointäkter i WeWeb med en diagramkomponent kopplad till en Xano-aggregeringsendpoint tar en halv dag att bygga och ger utdelning i säljarretention.

Lanseringschecklista

Innan du lanserar en marknadsplats: ☑ RLS-policyer på alla tabeller (köpare kan inte se andra köpares privata data, säljare kan inte se varandras stripe_account_id) ☑ Stripe webhook-handler för betalningshändelser (bekräftelse, tvister, återbetalningar) ☑ E-postaviseringar för alla bokningsstatusändringar (Make-automatisering) ☑ Admin-dashboard för tvistlösning ☑ Villkor, integritetspolicy och GDPR-samtycke (obligatoriskt i Sverige) ☑ Tillgänglighetstest (WCAG 2.1 AA), allt fler svenska upphandlingar kräver detta ☑ Lasttest med 100 samtida användare innan lansering

Ett vanligt misstag: att lansera utan admin-dashboarden. Inom den första veckan av en live-marknadsplats kommer du att behöva lösa en bokningstvist manuellt. Bygg admin-verktygen innan du går live.

Dessutom: testa hela cykeln från köpare till utbetalning med en riktig transaktion innan lansering, debitera ett riktigt kort, slutför bokningen, utlös en utbetalning till ett test-Stripe Connect-konto och verifiera att medlen anländer. Stripes sandlådeläge är utmärkt men det kan inte fånga varje gränsfall i din Xano-logik. En 1-euro testtransaktion fångade en webhook-timingbugg vid en av våra marknadsplatslanseringar som annars hade orsakat dubbeldebitering i skala. Det 10-minuters testet räddade en katastrofal produktionsincident.