Fra hjemmeside til platform: hvornår skal din side have login og database?

En hjemmeside med login og database er i praksis en webapp, og det spring ændrer både prisen, driften og dit ansvar for data. Du har brug for det når forskellige brugere skal se eller ændre deres egne oplysninger, fx ordrer, dokumenter, bookinger eller indhold de har betalt for. Er indholdet det samme for alle besøgende, har du ikke brug for login, uanset hvor stor siden ellers er.

Jeg bygger både hjemmesider og webapps, så læs med det forbehold. Mange ønsker der starter som "kunderne skal kunne logge ind", kan dog løses med en formular eller en færdig tjeneste, og dem peger jeg også på undervejs.

Den korte version

Det afgørende spørgsmål er ikke om siden skal være avanceret, men om forskellige brugere skal se forskellige data. Tabellen viser de behov jeg oftest hører, og om de faktisk kræver login og database.

Min beslutningsregel er kort. Skal forskellige brugere se data som ændrer sig løbende, og som kun de må se? Så er det en webapp. Ellers er det en hjemmeside, måske med et par tjenester koblet på. Har du allerede planer om en hel platform, så sammenligner min guide til at lave din egen platform de fire veje: standardløsning, no-code, kode den selv eller få den udviklet.

Hvad er forskellen på en hjemmeside og en platform?

Ordene bliver brugt løst, så her er hvordan jeg skelner. Der er tre niveauer, og de fleste virksomheder har brug for det første eller det andet.

Hjemmesiden

Alle besøgende ser det samme indhold. Du eller dine kolleger logger ind i et CMS (systemet hvor du redigerer tekster og billeder) for at rette siden, men det login er kun for redaktører. Siden er billig at hoste, og der ligger ingen kundedata i den ud over det der kommer ind via formularer.

Hjemmesiden med tjenester koblet på

Siden får hjælp fra færdige tjenester: et bookingværktøj, et betalingslink, et nyhedsbrev eller en chat. Brugerne opretter måske en konto, men kontoen og deres data ligger hos leverandøren. Du betaler et abonnement, og leverandøren står for sikkerheden.

Webappen

Nu har siden sine egne brugere og sin egen database (det strukturerede lager hvor systemet gemmer brugere, ordrer og alt det andet der ændrer sig). Login fortæller systemet hvem brugeren er. Rettigheder bestemmer hvad brugeren må se og gøre. Hver side bygges ud fra hvem der spørger, så koden skal køre på en server og kan ikke bare udleveres som færdige filer.

Det er springet fra andet til tredje niveau der koster. Ikke fordi selve login er svært at bygge, men fordi alt det der følger med, skal bygges, testes og passes.

Sådan vurderer du om din side skal have login: 5 trin

Gå de fem trin igennem før du beder om tilbud. De tager et par timer og kan spare dig for et projekt du ikke har brug for.

1. Skriv hvad brugeren skal kunne efter login. Formulér 3-5 opgaver med brugerens egne ord: "se min seneste faktura", "uploade dokumentation", "booke og aflyse en tid". Kan du ikke skrive dem, har du ikke brug for login endnu.
2. Find ud af hvilke data der skal gemmes, og hvor de kommer fra. Ligger oplysningerne allerede i dit økonomisystem, dit CRM eller et regneark, er den rigtige opgave ofte en integration og ikke en ny database. Notér også om der er persondata, for så er du dataansvarlig for dem.
3. Tjek om en færdig tjeneste kan klare det. Lukket indhold og abonnementer kan købes, og min guide til at bygge en medlemsplatform med login og betaling viser hvor grænsen går. Skal kunder se egne sager og dokumenter, så sammenlign white-label og custom-udviklet kundeportal før du beslutter dig.
4. Regn på både byggeri og drift. En webapp har en årlig regning som en hjemmeside ikke har. Brug tallene i de næste to afsnit som et groft første bud.
5. Beslut hvordan hjemmesiden og webappen skal hænge sammen. Skal login ligge i den eksisterende side, eller skal appen være et selvstændigt system ved siden af? Det påvirker både pris, synlighed på Google og hvem der kan rette hvad.

Hvad springet betyder for budgettet

Tabellen er mit grove skøn for 2026, ekskl. moms, når en erfaren freelanceudvikler i Danmark bygger løsningen. Spændene er store, fordi omfanget varierer meget fra projekt til projekt.

Det er sjældent antallet af skærmbilleder der afgør prisen på en webapp. Det gør antallet af brugertyper og rettigheder, integrationer til andre systemer, betaling og hvor meget der skal virke fra første dag. En kundeportal hvor kunderne kun læser egne dokumenter, er langt billigere end en hvor de også kan bestille, betale og invitere kolleger. Flere eksempler finder du i min prisguide til webapps med tre prisniveauer.

Den mest oversete post er den løbende. En hjemmeside kan stå nogenlunde stille i et par år. En webapp med brugere kan ikke, fordi sikkerhedsrettelser, nye browserversioner og ændringer hos de tjenester den taler med kræver arbejde hele tiden. Har appen kostet 250.000 kr., svarer min tommelfingerregel på 10-20 % til 25.000-50.000 kr. om året, før nye funktioner.

Hvad springet betyder for driften

Når brugerne logger ind, flytter ansvaret over til dig. Det er dig brugerne henvender sig til hvis noget går galt, også når fejlen ligger hos en leverandør. Fem ting skal have en ejer fra første dag.

1. Sikkerhed. Login er hoveddøren, så adgangskoder skal gemmes hashet (så de ikke kan læses, selv hvis databasen bliver stjålet), gentagne loginforsøg skal bremses, og totrinsbekræftelse skal være mulig. OWASP's anbefalinger om login viser hvad der forventes. Byg ikke login fra bunden. Laravels startpakker leverer fx login, nulstilling af adgangskode, bekræftelse af e-mail og totrinsbekræftelse.
2. Persondata. Gemmer du oplysninger om brugerne, er du dataansvarlig. Du skal kunne forklare hvad du gemmer og hvorfor, slette data efter en fast regel og have databehandleraftaler med de leverandører der behandler data for dig, fx hostingudbyderen og en udvikler med adgang til data. Datatilsynet forklarer rollerne som dataansvarlig og databehandler. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme oplysninger.
3. Backup og overvågning. Databasen er nu det mest værdifulde i systemet. Den skal sikkerhedskopieres automatisk, gendannelsen skal være afprøvet, og nogen skal have besked når appen er nede.
4. Support. "Jeg kan ikke logge ind" bliver en ny type henvendelse. Nogen skal kunne hjælpe brugere, låse konti op og slette brugere der beder om det.
5. Opdateringer. Framework, pakker og server skal holdes opdateret. Det er det arbejde de 10-20 % om året dækker.

Hvornår du ikke skal bygge login selv

Det billigste login er det du ikke selv skal passe. Jeg fraråder typisk en udviklet løsning når:

• en færdig tjeneste dækker det meste af behovet. Booking, nyhedsbreve, medlemsindhold og enkle kundeområder findes som abonnement, og det er som regel billigere at tilpasse arbejdsgangen til værktøjet end omvendt.
• du kun har en håndfuld kunder der skal se dokumenter. En delt mappe med adgangsstyring eller en mail med et sikkert link kan være nok i lang tid.
• du ikke har testet efterspørgslen. Lever tjenesten manuelt til de første kunder, og byg først når du ved hvad de bruger.
• budgettet kan dække byggeriet, men ikke driften. En webapp der ikke bliver vedligeholdt, bliver en sikkerhedsrisiko.

Har du allerede en WordPress-side, kan et medlemsplugin klare et enkelt lukket område, og så er en WordPress-udvikler et billigere valg end mig. Hvor grænsen går mellem de to verdener, har jeg beskrevet i WordPress vs custom-kodet hjemmeside. Vil du selv bygge en første version, kan no-code komme overraskende langt, og indlægget om no-code-platforme som Bubble, Softr og Glide viser hvor loftet typisk ligger.

Sådan hænger hjemmesiden og webappen sammen

Når du først skal have en webapp, er næste spørgsmål om den skal bo i hjemmesiden eller ved siden af. Der er to typiske modeller.

Samme system passer når den lukkede del er lille og tæt knyttet til indholdet, fx et medlemsområde med artikler i samme CMS som resten af siden. Det er billigst at starte med, men hjemmesidens CMS sætter grænsen for hvad appen kan.

Adskilte systemer er mit udgangspunkt når der er tale om en rigtig webapp. Hjemmesiden ligger på dinvirksomhed.dk og kan bygges i det CMS der passer til marketing, mens appen ligger på app.dinvirksomhed.dk med sin egen kode, database og hosting. Så kan du skifte hjemmeside uden at røre appen og opdatere appen uden at risikere salgssiderne. Med samme farver, skrifttyper og en log ind-knap i menuen oplever brugerne det som ét sted.

To ting gælder uanset model. Søgemaskiner logger ikke ind, så det der står bag login, bliver som udgangspunkt ikke fundet på Google. De sider der skal sælge, skal derfor være offentlige. Og din privatlivspolitik skal dække både hjemmesiden og appen, fordi appen gemmer langt mere end en kontaktformular.

Næste skridt

Brug tjeklisten før du taler med en udvikler eller en leverandør. Den gør det lettere at få tilbud du kan sammenligne.

Kan en færdig tjeneste klare det, så start der. Skal det bygges, starter jeg ved større opgaver med et betalt forprojekt til fast pris, hvor jeg sammen med dig afklarer brugere, data og integrationer og afleverer en plan og en pris. Du taler direkte med mig som udvikler hele vejen, og du ejer koden fra første dag. Se hvordan jeg arbejder med webapps og platforme med login og egne data.

Ofte stillede spørgsmål

Kan jeg starte med en hjemmeside og tilføje login senere?+

Ja, og det er ofte den rigtige rækkefølge. Byg hjemmesiden til det du har brug for nu, og tilføj webappen når behovet er bevist. Er siden bygget i et framework som Laravel eller Next.js, kan login lægges ind i samme kodebase. Er den bygget i Wix, Squarespace eller Webflow, bliver appen et separat system ved siden af, og det er sjældent et problem.

Kan brugerne logge ind med Google, Microsoft eller MitID?+

Ja. Login med Google eller Microsoft bygger på åbne standarder og understøttes af de fleste moderne frameworks og logintjenester. Det sparer brugerne for endnu en adgangskode og dig for support, og Microsoft-login er populært når brugerne er ansatte i andre virksomheder. MitID-login går typisk gennem en mellemmand, en såkaldt broker, og har sine egne omkostninger og krav. Det er mest relevant når du skal være sikker på hvem brugeren er.

Skal jeg bruge frameworkets eget login eller en ekstern logintjeneste?+

Frameworkets eget login er nok i de fleste projekter, og det holder brugerdata i din egen database. En ekstern tjeneste som Auth0, Clerk eller WorkOS er værd at overveje når dine kunder kræver single sign-on med deres virksomhedskonto, eller når flere apps skal dele samme login. Til gengæld får du endnu en leverandør, ofte en regning der vokser med antallet af brugere, og en databehandleraftale mere.

Hvor skal data fra en hjemmeside med login ligge?+

Som udgangspunkt på servere i EU. Det gør GDPR enklere, fordi du undgår overførsel af persondata til lande uden for EU. De fleste store hostingudbydere har datacentre i fx Frankfurt eller Irland. Husk at backup, mailafsendelse og fejlovervågning også behandler data, så de tjenester skal med i vurderingen og i dine databehandleraftaler.

Hvem ejer koden og brugerdata, når en udvikler bygger løsningen?+

Det afgøres af aftalen, så skriv det ind. Du bør eje både koden og data, og databasen bør ligge på en hostingkonto i dit navn, så du kan skifte udvikler uden at miste noget. Hos mig ejer du koden fra første dag. Bruger du en færdig tjeneste, ligger data hos leverandøren, så tjek hvordan du får dem ud igen, fx som eksport, før du binder dig.