Udvikle en markedsplads: sådan bygger du en tosidet platform
Sådan udvikler du en markedsplads: løs høne-æg-problemet, vælg betalingsflow og provision, byg tillid ind og skær første version ned til det nødvendige.

Freelance full-stack udvikler
- Udgivet
- Læsetid
- 12 min.
Indhold i indlægget9
Vil du udvikle en markedsplads, er koden sjældent det sværeste. Det svære er at få købere og sælgere til at dukke op samtidig, at lade pengene løbe sikkert fra køber over platformen til sælger og at skabe nok tillid til at fremmede tør handle med hinanden. Min anbefaling er at bygge den mindste version der kan gennemføre én rigtig handel fra start til slut, og vente med resten.
Jeg udvikler selv platforme som freelancer, så jeg har en interesse i emnet. Derfor er der også et afsnit om hvornår du ikke skal hyre en som mig.
Den korte version: byg i tre faser
En markedsplads bliver sjældent god af at blive bygget færdig på én gang. Den bliver god af at gå gennem tre faser hvor hver fase skal bevise at den næste er pengene værd.
| 1. Manuel test | 2. Færdig løsning eller no-code | 3. Udviklet første version | |
|---|---|---|---|
| Mål | Bevis at begge sider dukker op og handler | Gentag handler uden at du selv sidder i midten | Byg det der gør din markedsplads anderledes |
| Værktøjer | Formular, regneark, betalingslink og din telefon | En markedsplads-skabelon som Sharetribe eller et no-code-værktøj som Bubble | En custom webapp med fx Stripe Connect til betaling |
| Tid | Dage | Uger | Typisk 2-4 måneder for en slank version |
| Gå videre når | Du selv er blevet flaskehalsen | Værktøjet begrænser din model eller tager for stor en bid af provisionen | Data fra rigtige handler viser hvad næste udvidelse skal være |
Beslutningsreglen er enkel: gå først videre til næste fase når den nuværende fase er blevet flaskehalsen. Spring kun den manuelle fase over hvis du allerede har begge sider, fx fordi du i dag formidler handler i hånden eller har et netværk af sælgere klar.
Er du stadig i tvivl om en markedsplads overhovedet er den rigtige type platform til din idé, så start med min guide til at lave din egen platform. Den sammenligner færdige løsninger, no-code og udvikling. Resten af dette indlæg går ud fra at du har valgt markedspladsen og vil vide hvordan du bygger den.
Trin 1: Løs høne-æg-problemet før du skriver kode
En markedsplads uden sælgere tiltrækker ingen købere, og uden købere forsvinder sælgerne igen. Det kaldes høne-æg-problemet, og ingen mængde kode løser det. Det løses med afgrænsning og meget manuelt arbejde i starten.
Det jeg typisk anbefaler:
- Vælg en smal niche og et lille område. En markedsplads for tømrere i Aarhus kan have nok udbud til at køberne finder noget. En markedsplads for alle håndværkere i hele landet er tom de første mange måneder.
- Start med den side der er sværest at skaffe. Det er oftest sælgerne eller udbyderne, for køberne kommer når der er noget at købe. Ring til dem, mød dem, og opret deres profiler for dem hvis det er det der skal til.
- Gør platformen nyttig for den ene side alene. Kan sælgerne bruge platformen til noget de har brug for i forvejen, fx at sende tilbud, styre deres kalender eller få betaling, bliver de hængende før køberne kommer.
- Match i hånden. De første handler kan du formidle selv via mail og telefon. Det er langsomt, men du lærer præcis hvad køberne spørger om, og hvorfor handler falder til jorden.
- Mål likviditet, ikke tilmeldinger. Det tal der betyder noget, er hvor stor en andel af købernes forespørgsler der bliver til en handel, og hvor lang tid det tager. 500 sælgerprofiler uden handler er et dårligere tegn end 20 sælgere der alle har travlt.
Først når handler sker igen og igen, og du selv er blevet flaskehalsen, er det tid til at automatisere. Indtil da er hver krone brugt på udvikling en krone du ikke har brugt på at skaffe sælgere.
Trin 2: Find en provision der holder
Provisionen er platformens indtægt, typisk en procentdel af hver handel. Den kan betales af sælgeren, af køberen som et servicegebyr eller deles mellem dem. Der findes ikke én rigtig sats. Den afhænger af hvor meget platformen gør ud over selve mødet: betalingssikkerhed, fakturering, booking eller kunder som sælgeren ellers ikke ville have fundet.
Det mange glemmer, er at en del af provisionen går til betalingsgebyrer. Her er et regneeksempel med Stripes danske priser for Connect hvor platformen selv styrer gebyrerne over for sælgerne og tager 12 % i provision.
| Handel på 1.000 kr. | Handel på 200 kr. | |
|---|---|---|
| Provision | 120,00 kr. | 24,00 kr. |
| Kortgebyr for et almindeligt EØS-kort (1,5 % + 1,80 kr.) | 16,80 kr. | 4,80 kr. |
| Udbetaling til sælgeren (0,25 % + 5 kr.) | 7,20 kr. | 5,44 kr. |
| Aktiv sælgerkonto (15 kr. om måneden) | 15,00 kr. | 15,00 kr. |
| Tilbage til platformen | 81,00 kr. | minus 1,24 kr. |
Eksemplet går ud fra at sælgeren kun har én handel den måned og får den udbetalt for sig. Pointen er at de faste beløb rammer små handler hårdt. Du kan løse det ved at samle udbetalinger ugentligt eller månedligt, sætte en minimumsordre eller lade Stripe styre prisen over for sælgerne. I den sidste model betaler sælgerne selv gebyrerne, og platformen slipper for gebyrerne pr. konto og udbetaling, men du får mindre kontrol over hvad sælgerne betaler. Gebyrerne ændrer sig, så regn efter med de aktuelle priser før du lægger dig fast.
Når køber og sælger handler uden om dig
Den største trussel mod provisionen er at køber og sælger mødes på platformen og tager næste handel direkte. Det sker oftest ved ydelser hvor de samme to parter handler igen og igen, fx rengøring, undervisning eller en fast freelancer.
At skjule kontaktoplysninger hjælper kun lidt. Det der virker, er at gøre det mere bekvemt at blive: betaling og kvittering klares automatisk, anmeldelser tæller kun for handler gennem platformen, og køberen får pengene tilbage hvis noget går galt. Er relationen fast fra første handel, så overvej et abonnement for sælgerne i stedet for provision.
Trin 3: Design betalingsflowet
Betalingen er den tekniske kerne i en markedsplads. Pengene går fra køberen gennem platformen til sælgeren, og undervejs skal provisionen trækkes, gebyrer betales og refusioner kunne håndteres. Min klare anbefaling er at bruge en betalingsudbyder der er bygget til flere parter, fx Stripe Connect, frem for at modtage pengene på din egen konto og selv sende dem videre. Modtager platformen selv penge på vegne af sælgerne, kan det kræve en tilladelse fra Finanstilsynet, så få en jurist til at se på modellen før lancering.
En typisk handel ser sådan ud:
- Køberen betaler hele beløbet gennem platformen.
- Betalingsudbyderen trækker sit gebyr, og platformen beholder sin provision.
- Resten står på sælgerens konto hos betalingsudbyderen.
- Når ydelsen er leveret, eller fristen for at klage er udløbet, frigives pengene til sælgerens bankkonto.
Tre måder at sætte Stripe Connect op på
Stripe beskriver tre typer betalinger i Connect. Valget afgør hvem der står som modtager over for køberen, og hvem der hæfter for refusioner og tilbageførsler (chargebacks, hvor kortholderen får pengene tilbage via sin bank).
- Direct charges: køberen betaler direkte til sælgerens konto, og platformen får et gebyr. Passer når køberen reelt handler med sælgeren, og platformen mest er et værktøj.
- Destination charges: køberen betaler platformen, og en del sendes straks videre til sælgeren. Passer til de fleste markedspladser med én sælger pr. handel. Refusioner og tilbageførsler trækkes fra platformens saldo, og du kan derefter hente beløbet tilbage fra sælgeren.
- Separate charges and transfers: betaling og overførsel er adskilt. Det er nødvendigt når én kurv indeholder varer fra flere sælgere, eller når sælgeren først findes efter at køberen har betalt. Det er også den mest komplekse model at bygge.
Vil du holde pengene tilbage til opgaven er udført, kan du styre udbetalingerne manuelt. Stripe skriver dog i dokumentationen om manuelle udbetalinger at de ikke tilbyder escrow (deponering i juridisk forstand), og at pengene i de fleste lande skal udbetales inden for 90 dage. Det passer fint til en håndværkeropgave, men ikke til en booking der er betalt et halvt år før den finder sted.
Beslut også reglerne før koden: Hvornår må køberen annullere? Hvem betaler gebyret ved en refusion? Hvad sker der hvis sælgeren ikke dukker op? Svarene bliver til kode, og ubesvarede spørgsmål bliver til dyre ændringer midt i projektet.
Trin 4: Byg tillid ind fra første handel
På en markedsplads handler fremmede med hinanden. Køberen skal tro på at sælgeren leverer, og sælgeren skal tro på at pengene kommer. I starten har du ikke hundredvis af anmeldelser at læne dig op ad, så tilliden skal komme andre steder fra.
- Godkend sælgerne selv. En kort samtale eller et tjek af CVR-nummer og referencer er nok i starten, og det signalerer kvalitet over for køberne.
- Lad betalingsudbyderen tjekke identiteten. Med Stripe Connect står Stripe for at verificere sælgernes identitet og bankoplysninger, så du ikke selv skal opbevare kopier af pas og kontonumre.
- Hold betalingen på platformen. Når køberen ved at pengene først frigives når opgaven er udført, er det lettere at sige ja til en ukendt sælger.
- Skriv vilkårene ned. Annullering, refusion, klager og hvad platformen hæfter for, skal stå tydeligt før første handel. Få en jurist til at læse dem igennem.
- Gør profilerne konkrete. Billeder, priser, svartid og tidligere opgaver siger mere end en lang beskrivelse.
- Lad kun købere der har handlet, skrive anmeldelser. Så hører hver anmeldelse til en rigtig handel, og falske anmeldelser bliver sværere at plante.
Anmeldelser bliver først rigtig værdifulde når der er handler nok at anmelde. Indtil da gør din egen kvalitetskontrol mere for tilliden end stjerner gør.
Trin 5: Skær første version ned til én handel
Første version af en markedsplads skal kunne gennemføre én handel fra start til slut uden at du griber ind: sælgeren opretter sig og et opslag, køberen finder det og betaler, sælgeren leverer, og pengene bliver udbetalt. Alt der ikke er nødvendigt for den kæde, kan vente.
| I første version | Kan vente | |
|---|---|---|
| Matching | Køberen søger og filtrerer selv, eller du matcher manuelt | Automatisk matching og anbefalinger |
| Beskeder | E-mails ved hver ny status på en ordre | Chat i realtid |
| Betaling | Én valuta, kortbetaling og en fast provision | Flere valutaer, kurv med flere sælgere og abonnementer |
| Tillid | Manuel godkendelse af sælgere og klare vilkår | Anmeldelser, verificeringsmærker og automatisk svindelkontrol |
| Tvister | Du håndterer dem selv via mail og administrationen | Et automatiseret klageforløb |
| Administration | Godkend sælgere, ret opslag, refunder og eksportér data | Dashboards og roller til supportmedarbejdere |
| Apps | En webapp der fungerer godt på mobilen | Apps i App Store og Google Play |
Punkterne i kolonnen "I første version" er ikke valgfrie. Statusmails og en administration bliver tit glemt i budgettet fordi køberne aldrig ser dem, men uden dem sidder du og retter i databasen hver gang en handel går skævt.
Husk også de sælgeroplysninger du skal bruge til indberetning. Formidler platformen varesalg, tjenesteydelser eller udlejning, er du som udgangspunkt omfattet af EU's DAC7-regler. Reglerne er beskrevet på Skattestyrelsens side om DAC7. Byg felterne ind i sælgeroprettelsen fra start så du ikke skal jagte oplysningerne bagefter.
Vil du vide hvad hvert modul koster i timer og kroner, har jeg regnet det igennem i prisguiden til platforme og markedspladser.
Trin 6: Vælg byggevej og teknik
Når du har handler der gentager sig, har du tre veje til den første rigtige version:
- En færdig markedsplads-skabelon, fx Sharetribe. Det er hurtigst, og betaling med provision er bygget ind. Passer når din model ligner en almindelig markedsplads for udlejning, ydelser eller varer.
- No-code, fx Bubble. Du får mere frihed end i en skabelon, men logikken bliver svær at overskue efterhånden som reglerne vokser. Jeg har skrevet om hvor langt du kan komme med no-code-platforme.
- Custom udvikling. Det rigtige valg når din måde at matche, prissætte eller håndtere handler på er det der adskiller dig, eller når platformen skal hænge sammen med systemer du har i forvejen.
Vælger du custom, er mit udgangspunkt typisk Laravel til backend, administration og betalingslogik, React eller Next.js hvor brugerfladen kræver det, og Stripe Connect til betaling. Det vigtigste er dog ikke valget af teknologi, men at betalingskontoen, hostingen og koden står i dit navn fra første dag.
Der er to grænsetilfælde. Er din idé i virkeligheden booking af tider hos udbydere, så se min sammenligning af eget bookingsystem og standardløsninger. Sælger flere forhandlere fysiske varer, kan en webshop med flere leverandører være nok, og så hører valget hjemme i sammenligningen af Shopify, WooCommerce og en custom webshop.
Hvornår du ikke skal hyre en udvikler som mig
- Du har ikke gennemført handler endnu. Så er en manuel version eller en skabelon en billigere måde at blive klogere på.
- Du skal bruge native apps og flere udviklere på kort tid. Så har du brug for et bureau eller et team, ikke én freelancer.
- Dit budget rækker ikke til en slank første version. Så er en skabelon bedre end en halvfærdig custom-platform.
Næste skridt
Før du får udviklet din markedsplads, så gå listen herunder igennem. Kan du ikke krydse det meste af, er du stadig i fase 1 eller 2, og det er helt i orden.
Klar til at få udviklet din markedsplads?
- Kerneflow: du kan sige i én sætning hvem der sælger hvad til hvem, og hvordan der betales.
- Rækkefølge: du ved hvilken side du skaffer først, og har talt med rigtige sælgere.
- Handler: du har gennemført rigtige handler manuelt eller i en færdig løsning.
- Provision: provisionen dækker gebyrerne også ved din mindste typiske handel.
- Pengene: du har besluttet hvornår pengene frigives, og hvem der bærer tabet ved refusion og tilbageførsel.
- Vilkår: reglerne for annullering, refusion og klager er skrevet ned.
- Omfang: første version kan beskrives på én side.
- Ejerskab: betalingskonto, hosting og kode står i dit navn.
Kan du krydse det meste af, er næste skridt at få planen udfordret af den der skal bygge den. Jeg starter større platforme med et betalt forprojekt til fast pris. Her fastlægger jeg sammen med dig betalingsflow, regler og omfanget af første version. Du har direkte kontakt med den udvikler der skriver koden, og koden er din fra dag ét. Se hvordan jeg arbejder med udvikling af webapps og platforme.
Ofte stillede spørgsmål
Hvor lang tid tager det at udvikle en markedsplads?
En slank første version tager typisk 2-4 måneder med én erfaren udvikler, når omfanget er afklaret. Dertil kommer tiden før: et forprojekt på nogle uger og gerne en periode med manuelle handler, så du ved hvad du bygger. Det der oftest forsinker projektet, er ikke koden, men beslutninger om provision, refusion og vilkår som først bliver truffet undervejs.
Hvad er forskellen på en markedsplads og en webshop?
I en webshop sælger du dine egne varer, og pengene går til dig. På en markedsplads sælger andre, og du formidler handlen mod en provision. Det betyder at pengene skal fordeles mellem flere parter, at sælgerne skal oprettes og godkendes, og at du skal indberette sælgeroplysninger. Derfor er en markedsplads mere kompleks at bygge og drive end en webshop med samme antal varer.
Skal provisionen betales af køberen eller sælgeren?
Start med at lade den side betale der får mest ud af platformen, og som er mindst følsom over for prisen. Ofte er det sælgeren fordi platformen skaffer kunder vedkommende ellers ikke ville have fået. Et servicegebyr til køberen kan være fornuftigt når platformen også giver køberen noget, fx betalingssikkerhed. Hold modellen simpel i starten, og test en ændring på nye sælgere før du ændrer den for alle.
Hvordan håndterer jeg tvister mellem køber og sælger i starten?
Manuelt og efter regler du har skrevet ned på forhånd. Hold pengene tilbage til opgaven er godkendt, bed begge parter om dokumentation som billeder eller beskeder, og træf en afgørelse ud fra dine vilkår. Refusionen kan du lave fra administrationen. Et automatiseret klageforløb er først pengene værd når tvisterne bliver så mange at de tager en fast del af din uge.