Typer af udviklereSammenligning
enRead in EnglishFrontend vs backend vs fullstack: forskellen forklaret for købere
Frontend vs backend vs fullstack forklaret for købere: hvad hvert lag i en webapp gør, hvem der bygger det, og hvilken udvikler dit projekt har brug for.

Freelance full-stack udvikler
- Udgivet
- Læsetid
- 10 min.
Indhold i indlægget8
Forskellen på frontend vs backend er hvor i en webapp udvikleren arbejder. Frontend er det brugeren ser og klikker på i browseren, backend er logikken, data og integrationerne bag skærmen, og en fullstack-udvikler arbejder i begge lag. Som køber skal du vælge ud fra hvor det svære i dit projekt ligger, ikke ud fra titlen på udviklerens profil.
Jeg er selv fullstack-udvikler, så læs med det forbehold. Jeg har forsøgt at være lige så konkret om de projekter hvor en specialist er det bedre valg.
Den korte version
| Frontend | Backend | Fullstack | |
|---|---|---|---|
| Arbejder i | Brugerfladen i browseren | Server, database og API'er | Begge lag |
| Typiske værktøjer | HTML, CSS, JavaScript, React, Vue | PHP og Laravel, Node.js, Python, C#, SQL | En kombination, fx Laravel og React |
| Hyr når | Brugeroplevelsen er det svære | Data, regler og integrationer er det svære | Hele løsningen skal bygges |
| Fejl rammer | Det brugeren ser og klikker på | Dine data, sikkerheden og beregningerne | Begge dele |
| Passer dårligt når | Der ikke findes en backend endnu | Brugerfladen er en stor del af opgaven | Ét lag kræver dybt specialistniveau |
| Personer at koordinere | Mindst to hvis du starter fra bunden | Mindst to hvis du starter fra bunden | Én |
| Pris | Afhænger mest af erfaring | Afhænger mest af erfaring | Ofte lavere samlet pris fordi overdragelser forsvinder |
Min beslutningsregel er enkel. Har du ingen løsning i forvejen, så start med en fullstack-udvikler. Har du allerede det ene lag, eller er ét lag usædvanligt krævende, så hyr en specialist til netop det lag. Leder du efter andre roller end de tre, fx app-, data- eller AI-udviklere, så se min oversigt over typer af udviklere og hvad de laver.
En webapp skåret i lag
Det er lettere at vælge når du kan se hvad lagene består af. Tag en kundeportal hvor en kunde logger ind og henter en faktura. Det ene klik går igennem fem lag:
- Brugerfladen: Kunden ser en liste over fakturaer og trykker på "Download". Listen, knappen og hvordan siden opfører sig på telefonen er frontend.
- API'et: Browseren sender en forespørgsel til serveren via et API, en fast snitflade hvor frontend og backend taler sammen. Hvor godt API'et er beskrevet, afgør hvor godt de to lag passer sammen.
- Forretningslogikken: Serveren tjekker at kunden er logget ind og kun kan se sine egne fakturaer. Her bor reglerne om rettigheder, beregninger og rabatter, alt det der er særligt for din forretning. Det er backend.
- Databasen: Fakturaen hentes fra databasen. Hvordan data er struktureret, bestemmer hvor let det bliver at bygge videre senere. Også backend.
- Integrationer og drift: PDF'en kommer måske fra dit økonomisystem, og det hele kører på en server der skal opdateres, overvåges og tages backup af. Integrationer er typisk backend, mens driften kan ligge hos backend-udvikleren, fullstack-udvikleren eller en specialist.
Frontend-udvikleren ejer lag 1. Backend-udvikleren ejer lag 3, 4 og som regel 5. Lag 2 er grænsen mellem dem, og det er her projekter med to udviklere eller to leverandører oftest går i stå: den ene venter på den anden, eller de har forstået et felt forskelligt. En fullstack-udvikler ejer alle lag, også grænsen.
Bliver driften i lag 5 kompleks eller forretningskritisk, er det en opgave for sig. Jeg har skrevet om hvornår en lille virksomhed har brug for en DevOps-ingeniør, hvis du er i tvivl om du er nået dertil.
Sådan finder du det svære lag i dit projekt
Du behøver ikke kunne kode for at se hvor kompleksiteten ligger. Beskriv projektet med dine egne ord, og se hvilke af sætningerne her der minder mest om dit:
- "Brugerne skal kunne trække, filtrere og se ændringer med det samme": det svære er frontend.
- "Det skal hænge sammen med vores økonomisystem, lager og CRM": det svære er backend.
- "Forskellige brugere må se og rette forskellige ting": backend, fordi rettigheder skal håndhæves på serveren.
- "Vi har allerede en app, men den mangler et system bagved": backend.
- "Systemet virker, men ingen kan finde ud af at bruge det": frontend, og måske en designer.
- "Vi har ingenting endnu og skal have en første version i drift": fullstack.
Fordeler sætningerne sig nogenlunde jævnt, er en fullstack-udvikler som regel det enkleste valg. Dominerer én kategori, og er projektet stort, kan det betale sig at have en specialist på netop det lag, enten alene eller ved siden af en fullstack-udvikler.
Typiske projekter i små og mellemstore virksomheder, fx kundeportaler, bookingsystemer, interne værktøjer og første versioner af SaaS-produkter, har det svære i backend. Brugerfladen skal være klar og hurtig, men sjældent eksperimenterende. Den slags projekter passer bedst til en fullstack-udvikler med et stærkt backend-ben.
Hvad hver profil bygger, og hvornår du skal bruge den
Her er de tre profiler lidt mere detaljeret, med de opgaver hver af dem er stærkest i.
Frontend-udvikler
En frontend-udvikler bygger det der kører i brugerens browser: sider, formularer, menuer, tabeller og grafer der virker på både telefon og stor skærm. Opgaven er også at siden indlæses hurtigt, kan bruges med tastatur og skærmlæser, og opfører sig forudsigeligt når brugeren gør noget uventet. Sælger du online, er din webshop som udgangspunkt omfattet af EU's tilgængelighedsdirektiv (European Accessibility Act), og en stor del af det arbejde ligger i frontend.
Du har brug for en specialiseret frontend-udvikler når brugeroplevelsen er det svære. Det kan være et planlægningsværktøj med træk og slip, et dashboard med mange filtre og grafer, en lang ansøgningsformular hvor spørgsmålene ændrer sig undervejs, eller et produkt som brugerne sidder i hele arbejdsdagen. Det er også det rigtige valg hvis du har en backend eller et API i forvejen og mangler en ny brugerflade ovenpå.
En frontend-udvikler er ikke det samme som en designer. Mange kan lidt af begge dele, men brugerresearch og visuel identitet er et andet fag. Om du skal starte med en UX/UI-designer eller en udvikler, har jeg skrevet et særskilt indlæg om.
Backend-udvikler
En backend-udvikler bygger det brugeren ikke ser: databasen, forretningsreglerne, login og rettigheder, betaling, API'er og integrationer til andre systemer. Fejl i backend er dyre fordi de rammer dine data og ikke bare skærmbilledet. En forkert beregning eller en kunde der kan se en anden kundes oplysninger, er et backend-problem, og det sidste kan også være et brud på persondatasikkerheden efter GDPR.
Hyr en backend-udvikler når det svære ligger i data og regler. Det kan være en integration mellem dit ERP-system og en webshop, en prisberegning med mange undtagelser, et system hvor brugere med forskellige roller arbejder i de samme data, eller et API som dine samarbejdspartnere skal bruge. Har du allerede en app eller en frontend fra en anden leverandør, kan en backend-udvikler bygge laget bag.
Fullstack-udvikler
En fullstack-udvikler kan bygge alle fem lag. Det er også den mest udbredte titel: i Stack Overflows udviklerundersøgelse fra 2025 beskriver 27 % af de adspurgte sig som fullstack, mod 14,2 % backend og 4,3 % frontend. Netop fordi titlen er så almindelig, siger den ikke meget i sig selv.
De fleste fullstack-udviklere har et stærkt ben og et der er godt nok. Jeg arbejder selv med Laravel og PHP i backend og React, Next.js og Tailwind CSS i frontend. Spørg altid hvilket lag udvikleren selv mener er det svageste, også mig. Hvornår én person kan klare hele projektet og hvornår du skal bruge flere, gennemgår jeg i guiden til hvornår én fullstack-udvikler er nok.
Hvornår hver profil ikke passer
Frontend-udvikler alene
Ikke når der mangler en backend. En frontend-udvikler kan bygge en flot prototype, men login, data og integrationer ender enten i hjemmelavede løsninger eller i en færdig tjeneste der ikke passer til din forretning. Det er heller ikke det rigtige valg hvis problemet i virkeligheden er at systemet regner forkert, eller at det er langsomt fordi databasen er bygget forkert. Det løser en ny brugerflade ikke.
Backend-udvikler alene
Ikke når brugerfladen er en stor del af produktet. Mange backend-udviklere kan bygge en brugerflade der virker, men ikke nødvendigvis en som dine kunder har lyst til at bruge. Til et internt administrationsværktøj er det ofte fint. Til et produkt du skal sælge, eller en løsning hvor kunderne skal klare sig uden support, er det en risiko.
Fullstack-udvikler
Ikke når ét lag kræver dybt specialistniveau. Det kan være samarbejde i realtid hvor flere redigerer det samme dokument på én gang, meget store datamængder der skal behandles hurtigt, eller tunge sikkerhedskrav. Det passer heller ikke når der skal bygges meget på kort tid, fordi én person har et begrænset antal timer, mens to specialister kan arbejde parallelt. Og skal du have et brand og en visuel identitet, er det en designer du skal bruge, ikke en udvikler.
Hvad titlen betyder for prisen
Timeprisen afhænger mere af erfaring end af om udvikleren kalder sig frontend, backend eller fullstack. En erfaren frontend-specialist i store React-projekter kan sagtens koste mere end en mindre erfaren backend-udvikler. Sammenlign derfor erfaring med den type opgave du har, ikke titler.
Den største forskel i den samlede pris kommer fra antallet af personer. To specialister betyder to timepriser, et API der skal aftales i detaljer, og ofte en tredje person der koordinerer. Med én fullstack-udvikler betaler du ikke for overdragelser mellem lagene, men du får heller ikke den fart som to personer der arbejder parallelt kan give. Vil du sammenligne økonomien i at ansætte, hyre en freelancer eller bruge et bureau, har jeg samlet det i et indlæg om hvad en udvikler koster i de forskellige modeller.
Næste skridt
- Skriv tre til fem sætninger om hvad brugerne skal kunne og hvilke systemer løsningen skal tale med.
- Markér hvilke sætninger der handler om brugerfladen og hvilke der handler om data, regler og integrationer.
- Tjek hvad du har i forvejen. Har du en backend, en app eller et færdigt design, skal du kun bruge en udvikler til det der mangler.
- Spørg udvikleren hvilket lag vedkommende er stærkest i, og bed om at se noget i drift i netop det lag.
Er du stadig i tvivl, så brug guiden der matcher projekttype med udviklertype. Og vil du se om dit projekt passer til mig, kan du læse om de projekter jeg tager på mig som freelanceudvikler.
Ofte stillede spørgsmål
Hvordan tester jeg om en fullstack-udvikler er stærk i begge lag?
Bed om at se to ting i drift: en brugerflade udvikleren selv har bygget, og et eksempel på en integration eller en datamodel. Spørg derefter hvilket lag udvikleren selv mener er det svageste, og hvad vedkommende gør når en opgave ligger uden for det. Et ærligt svar med konkrete grænser er et bedre tegn end en påstand om at være lige stærk i alt.
Skal jeg have en anden udvikler hvis jeg også vil have en app?
Ikke nødvendigvis. En webapp der fungerer godt på telefonen, kan en fullstack-udvikler bygge. Skal appen ligge i App Store og Google Play, er det en ekstra frontend, og den kræver ofte en appudvikler. Backend kan som regel genbruges, så appen og webløsningen henter data fra det samme API. Bed derfor om at backend bliver bygget med det for øje fra starten.
Hvad betyder det at en løsning er headless?
Headless betyder at frontend og backend er helt adskilt og kun taler sammen via et API. Det er almindeligt i webshops og CMS'er, hvor indholdet styres ét sted og vises på hjemmeside, app eller skærme. Fordelen er fleksibilitet. Ulempen er at du får to dele at vedligeholde, og dermed enten to profiler eller én fullstack-udvikler der er vant til opsætningen.
Kan en frontend-udvikler gøre min eksisterende løsning pænere?
Ja, hvis brugerfladen kan ændres uden at røre logikken bagved. I nyere løsninger hvor frontend henter data fra et API, kan en frontend-udvikler arbejde ret frit. I ældre systemer hvor brugerflade og logik er blandet sammen i den samme kode, kræver selv små ændringer ofte en der også forstår backend. Bed om en kort gennemgang af koden før du sætter et redesign i gang.