Lav din egen platform: byg selv, no-code eller få den udviklet?

Vil du lave din egen platform, har du fire veje: lej en færdig standardløsning, byg selv med no-code, kod den selv eller få den udviklet. Min tommelfingerregel er at starte med den billigste vej der kan klare dit kerneflow, og først få platformen udviklet når det der gør dig anderledes, ikke kan bygges i et standardværktøj. Reglen holder for markedspladser, medlemsplatforme, bookingsystemer og kundeportaler.

Jeg lever selv af at udvikle platforme, så læs med det forbehold. Derfor skriver jeg også ærligt om hvornår du ikke skal hyre en som mig.

Den korte version: fire veje til din egen platform

Tabellen viser hovedforskellene, men selve beslutningsreglen er enkel. Kan en færdig løsning klare det meste af dit kerneflow, så start der. Kan den ikke, så byg en prototype i no-code eller test idéen manuelt. Få platformen udviklet når idéen er testet på rigtige brugere, eller når det du skal bygge, er præcis det som standardværktøjerne ikke kan.

Med kerneflow mener jeg den ene handling platformen findes for: en kunde booker og betaler, et medlem logger ind og ser indhold, en køber finder en sælger.

Hvilken slags platform vil du bygge?

"Platform" dækker over meget. Fire typer går igen, og de er svære på hver sin måde. Det er nyttigt at vide hvilken type du står med, for det afgør hvor godt standardværktøjerne passer.

Markedsplads

En markedsplads forbinder to grupper, typisk købere og sælgere eller kunder og leverandører. Det tekniske kerneproblem er pengene. Køberen betaler, platformen tager en kommission, og sælgeren skal have resten udbetalt. Det kræver en betalingsløsning bygget til flere parter, fx Stripe Connect, og faste regler for refusion, annullering og uenigheder.

Det største problem er dog sjældent teknikken. En markedsplads uden sælgere tiltrækker ingen købere, og omvendt. Derfor anbefaler jeg typisk at starte med en færdig markedsplads-skabelon eller endda manuelt formidlingsarbejde, indtil du har vist at begge sider dukker op. Når du er klar til næste skridt, har jeg skrevet en guide til at udvikle en tosidet markedsplads.

Medlems- og kursusplatform

Her logger brugerne ind, betaler et abonnement eller et engangsbeløb og får adgang til indhold: artikler, video, kurser eller et fællesskab. Det er den type hvor standardværktøjerne er mest modne. Login, betaling og adgangsstyring er løste problemer, og du kan være i gang på kort tid.

Udvikling bliver relevant når medlemsdata skal hænge sammen med andre systemer, når du har særlige roller (fx trænere, klubber eller virksomhedskunder med mange brugere), eller når indholdet er mere interaktivt end et kursusværktøj kan håndtere. Jeg går i dybden med at bygge en medlemsplatform med login, betaling og indhold og med valget mellem at bygge en kursusplatform selv eller bruge en færdig.

Bookingsystem

Et bookingsystem holder styr på tider, ressourcer og betaling. En kunde vælger en tid, betaler eller reserverer og får en påmindelse. Til frisører, klinikker, mødelokaler og holdtræning findes der mange færdige systemer, og de er som regel det rigtige valg.

Det bliver svært når reglerne er dine egne: priser der afhænger af tidspunkt og kundetype, ressourcer der skal bookes sammen (et lokale og en instruktør på samme tid), kapacitet der skal fordeles mellem flere kanaler, eller bookinger der skal over i et kassesystem eller økonomisystem. Det er typisk her standardsystemerne kommer til kort. Sammenligningen af eget bookingsystem og standardløsning hjælper dig med at finde grænsen.

Kundeportal og interne værktøjer

En kundeportal giver dine kunder et sted at logge ind og se ordrer, dokumenter, sager eller rapporter. Et internt værktøj gør det samme for dine medarbejdere og erstatter ofte regneark og lange mailtråde. Værdien ligger næsten altid i integrationen: portalen er kun nyttig hvis den viser data fra dit økonomisystem, dit CRM eller dit lagersystem.

Ligger dine data i gængse systemer, er en white-label-portal (en færdig portal med dit logo) et godt udgangspunkt. Er dine processer særlige, er en udviklet portal ofte billigere på lang sigt end at bøje processen efter værktøjet. Se sammenligningen af kundeportal som custom-udvikling eller white-label, valget mellem at bygge eller købe et intranet og tegnene på at virksomheden er vokset ud af Excel.

Sælger du fysiske varer, er det en webshop og ikke en platform, og så står valget mellem Shopify, WooCommerce eller en custom-udviklet webshop. Har du en hjemmeside i dag og overvejer at give brugerne login, så start med hvornår en hjemmeside skal have login og database.

Hvad koster det, og hvor lang tid tager det?

Pris og tid afhænger af vejen du vælger, men også af hvor meget du selv lægger i det. En no-code-platform er billig i kroner og dyr i timer. En udviklet platform er dyr i kroner, men tager mindre af din egen tid.

Værktøjspriserne kommer fra Sharetribes prisside og Bubbles prisside, begge tjekket i oktober 2026. Begge afregner i dollar, og prisen stiger med forbruget.

Skønnet for udvikling bygger på en simpel regning. LønRadar angiver 800-1.200 kr. i timen ekskl. moms for senior freelance-it-konsulenter i Danmark i 2026. Som groft skøn kræver en afgrænset første version af en kundeportal, et bookingsystem eller en medlemsplatform ofte 150-400 timer. En markedsplads med betaling til flere parter ligger typisk i den høje ende eller over. Bureauer ligger som regel højere, fordi timeprisen også dækker projektledelse og bureauets drift.

Det der driver prisen op

• Antallet af brugertyper. En platform med én slags bruger er langt enklere end en med kunder, leverandører og administratorer, der hver ser noget forskelligt.
• Betalingen. Et engangskøb er enkelt. Abonnementer, fakturaer til virksomheder og udbetaling til flere parter er ikke.
• Integrationer. Hver forbindelse til et andet system (økonomi, CRM, lager, kalender) skal bygges, testes og vedligeholdes.
• Administration. Nogen skal kunne godkende brugere, rette fejl og trække rapporter, og den del bliver tit glemt i budgettet.
• App eller web. En webapp der virker godt på mobilen, er billigst. En app i App Store og Google Play koster ekstra.
• Persondata. Følsomme oplysninger, fx helbredsdata, stiller større krav til sikkerhed og dokumentation.

Glem heller ikke den løbende udgift. Abonnementer på færdige løsninger stiger ofte med antallet af brugere eller transaktioner, og en udviklet platform skal holdes opdateret. Hvordan jeg selv prissætter projekter, med et betalt forprojekt og en fast pris, kan du se på prissiden.

Hvornår en færdig løsning eller no-code er det rigtige valg

En færdig løsning er det rigtige når dit behov ligner mange andres. Skal kunderne booke en tid, skal medlemmer have adgang til video, eller skal du teste om en markedsplads overhovedet kan tiltrække sælgere, så findes der værktøjer der gør det i morgen. Du betaler et abonnement, og leverandøren står for drift, sikkerhed og opdateringer.

No-code er det rigtige når en færdig løsning ikke helt passer, men du endnu ikke ved nok til at få noget udviklet. Det er også et godt valg til interne værktøjer med få brugere og til en prototype du kan vise kunder eller investorer. Den største fordel er at du kan ændre den selv, samme dag. Hvor langt du kan komme, har jeg gennemgået i indlægget om Bubble, Softr og Glide og deres grænser.

Hvad med at kode den selv med AI?

AI-kodeværktøjer som Lovable, Bolt og Cursor kan på kort tid lave noget der ligner en færdig app. Til en prototype er det fint. Men det svære ved en platform er sjældent skærmbillederne. Det er login, roller og rettigheder, betaling, backups, sikkerhedsopdateringer og hvad der sker når to brugere ændrer det samme på samme tid. Skal platformen håndtere rigtige kunders data og penge, skal nogen kunne læse koden og stå inde for den.

Hvornår det ikke passer

• Når din proces er din konkurrencefordel, og værktøjet tvinger dig til at arbejde som alle andre.
• Når prisen pr. bruger, transaktion eller forbrug vokser hurtigere end din omsætning.
• Når du har brug for integrationer som værktøjet ikke har, og omvejene med automatiseringskæder og manuelle eksporter begynder at koste timer hver uge.
• Når du skal kunne tage platformen med dig. Ifølge Bubbles egen FAQ kan du fx eksportere dine data, men der er ingen kodebase du kan tage med og køre et andet sted.
• Når investorer, store kunder eller en kommende køber vil vide hvem der ejer teknologien.

Afvejningen mellem at leje og eje har jeg skrevet mere om i skræddersyet software over for standardsoftware.

Hvornår du skal have platformen udviklet

Udvikling er det rigtige valg når et eller flere af disse punkter passer på dig:

• Platformen er selve forretningen, og du forventer at udvikle på den i årevis.
• Din måde at arbejde på er det kunderne betaler for, og den passer ikke ind i et standardværktøj.
• Platformen skal tale sammen med systemer du allerede bruger.
• Du har testet idéen, har brugere eller kunder der venter, og ved hvad første version skal kunne.
• Summen af abonnementer, gebyrer og manuelle omveje er ved at blive større end prisen for at eje løsningen.

Når du får platformen udviklet, ejer du koden og kan bygge præcis det der er brug for. Til gengæld ejer du også ansvaret for hosting, opdateringer, sikkerhed og videreudvikling. Lanceringen er starten og ikke målstregen. Sæt derfor penge af til drift og vedligehold fra dag ét, ikke kun til selve udviklingen.

Hvornår du ikke skal hyre en som mig

• Når du ikke har testet om nogen vil bruge platformen. Brug en færdig løsning eller no-code først, og spar pengene til du ved mere.
• Når en standardløsning dækker dit behov. Så er det spild at betale for at genopfinde den.
• Når projektet kræver brand, design, tekster og markedsføring i samme omgang. Så er et bureau med flere fagligheder ofte et bedre match end en enkelt udvikler.
• Når ingen hos dig har tid til at træffe beslutninger undervejs. En udvikler kan ikke gætte sig til din forretning.

Sådan griber du det an i seks trin

Uanset hvilken vej du ender med, er de første skridt de samme. Rækkefølgen er vigtig, fordi hvert trin gør det næste billigere.

1. Skriv kerneflowet i én sætning, fx "En kunde finder en ledig tid, betaler og får en påmindelse dagen før." Kan du ikke skrive den sætning, er du ikke klar til at vælge teknologi.
2. Kortlæg brugertyper og pengestrøm. Hvem logger ind, hvad ser de, og hvem betaler hvem hvornår? Tegn det gerne på et stykke papir. Det er grundlaget for ethvert prisoverslag.
3. Afprøv to eller tre færdige løsninger mod kerneflowet. De fleste har en gratis prøveperiode. Skriv ned præcis hvor de ikke slår til, for den liste bliver din kravliste, uanset hvad du vælger bagefter.
4. Test efterspørgslen før du bygger. En formular, et regneark og et betalingslink kan ofte simulere en platform for de første kunder. Tjener idéen penge med manuelle håndgreb, er den værd at automatisere. Guiden til at digitalisere en manuel arbejdsgang viser hvordan du kortlægger processen først.
5. Afgræns første version. Skriv både hvad der er med, og hvad der bevidst ikke er med. Avancerede rapporter, en app i App Store og finmaskede roller kan næsten altid vente.
6. Få et forprojekt og en fast pris på første etape. Et kort, betalt forprojekt (en afklaring før selve udviklingen) bør ende med en prioriteret liste over funktioner, skitser af de vigtigste skærmbilleder, et teknologivalg, en tidsplan og en pris du kan regne med. Det er sådan jeg selv arbejder med større platforme, og det beskytter begge parter mod overraskelser.

Tjek dig selv før du vælger

Kan du sætte flueben ved de fleste punkter herunder, er du klar til at vælge vej. Mangler du flere, er de næste uger bedre brugt på at finde svarene end på at bygge.

Fire fejl der gør platforme dyre

Den første fejl er at bygge det hele på én gang. Administrationspanel, mobilapp, alle brugertyper og alle betalingsformer i første version gør projektet dyrt og langsomt, og du lærer først hvad brugerne faktisk vil have, når det er bygget. En lille version der løser kerneflowet godt, giver dig svar langt hurtigere, og de næste etaper kan bygges på det du har lært i stedet for på gæt.

Den anden fejl er at glemme driften. En platform skal have sikkerhedsopdateringer, backups, overvågning og nogen der svarer når noget går galt. Det gælder også no-code, hvor du selv er den der skal rette fejlene. Læg en plan for hvem der passer på platformen, før den går i luften.

Den tredje fejl er at låse sig fast uden en vej ud. Uanset vej skal domænet, betalingskontoen (fx din egen Stripe-konto) og dine data stå i dit navn. Bruger du et værktøj der gemmer persondata for dig, skal du også have en databehandleraftale med leverandøren. Får du platformen udviklet, så kræv at koden ligger i dit eget repository (kodearkiv) fra første dag.

Den fjerde fejl er at al viden sidder i ét hoved. Det gælder medarbejderen der byggede jeres no-code-app på en weekend, og det gælder udvikleren der har skrevet koden. Bed om en kort beskrivelse af hvordan platformen hænger sammen, hvilke eksterne tjenester den bruger, og hvem der har adgang til hvad. Så kan en anden tage over hvis det bliver nødvendigt.

Næste skridt

Start med kerneflowet, test det med den billigste vej der virker, og få først platformen udviklet når du ved hvad den skal kunne. Står du med en markedsplads, en medlemsplatform, et bookingsystem eller en kundeportal, er indlægget om netop den type det bedste sted at fortsætte. De går længere ned i funktioner, faldgruber og pris end der er plads til her, og de er skrevet så du kan bruge dem som grundlag for en snak med en udvikler eller en leverandør.

Er du nået dertil hvor platformen skal udvikles, kan du se hvordan jeg arbejder med webapps og platforme. Du taler direkte med mig som udvikler, større projekter starter med et betalt forprojekt til fast pris, og koden er din fra første dag.

Ofte stillede spørgsmål

Kan jeg starte i no-code og få platformen udviklet senere?+

Ja, og det er ofte en fornuftig plan. Regn bare med at selve appen skal bygges forfra, for no-code-værktøjer lader dig typisk kun tage dine data med. Til gengæld har du lært hvad brugerne faktisk bruger, og det gør den udviklede version mindre og billigere. Sørg for at data kan eksporteres, og at betalinger kører gennem din egen konto.

Skal min platform være en app i App Store?+

Sjældent i første omgang. En webapp der virker godt på mobilen, kan bruges med det samme uden download, og du slipper for at vente på godkendelse i App Store og Google Play. En rigtig app er pengene værd når brugerne åbner platformen flere gange om dagen eller har brug for funktioner som push-beskeder og kamera.

Hvad kræver GDPR af min platform?+

GDPR kræver blandt andet at du ved hvilke persondata platformen gemmer og hvorfor, at du fortæller brugerne det i en privatlivspolitik, og at du kan udlevere eller slette en brugers data når vedkommende beder om det. Byg det ind fra start, for det er dyrere at tilføje bagefter. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme oplysninger.

Hvem ejer koden hvis en freelancer bygger platformen?+

Det afhænger af aftalen. Ophavsretslovens regel om at rettigheder til et program automatisk går til arbejdsgiveren, gælder for ansatte og ikke for freelancere. Derfor skal kontrakten sige at rettighederne overdrages til dig. Hos mig ejer kunden koden fra første dag, men få altid kontrakten tjekket hvis der står meget på spil.