Fullstack-udvikler: hvornår er én udvikler nok til hele projektet?
Hvornår kan én fullstack-udvikler bygge hele dit projekt, og hvornår skal du bruge et team? En ærlig tommelfingerregel, en test i 6 trin og en tjekliste.

Freelance full-stack udvikler
- Udgivet
- Læsetid
- 10 min.
Indhold i indlægget9
En fullstack-udvikler kan sagtens bygge hele dit projekt alene når produktet har én klar kerne, tidsplanen passer til én persons kapacitet, og du ikke har brug for nogen på vagt døgnet rundt. Du har brug for et team når flere ting skal bygges samtidig, når design fylder meget i opgaven, eller når produktet kræver specialviden som én person ikke kan dække.
Jeg arbejder selv på den måde: én udvikler med ansvaret for hele løsningen. Læs derfor teksten med det forbehold. Jeg har forsøgt at være lige så tydelig om grænserne som om fordelene.
Den korte version
| Én udvikler er nok | Du har brug for et team | |
|---|---|---|
| Produkt | Ét produkt med en klar kerne, fx en kundeportal, første version af en SaaS eller et internt værktøj | Flere produkter eller platforme der skal bygges samtidig |
| Tidsplan | En deadline der passer til én persons arbejdstimer | En fast lanceringsdato der kræver mere arbejde end én person kan nå |
| Design | Enkelt design, et færdigt designsystem eller skitser fra en designer | Ny visuel identitet og brugerresearch som en del af projektet |
| Specialviden | Almindelig webudvikling: data, brugere, betaling og integrationer | Fx egne maskinlæringsmodeller, tunge regulatoriske krav eller meget store datamængder |
| Efter lancering | Opdateringer, rettelser og videreudvikling i et roligt tempo | Vagtordning døgnet rundt og daglig udvikling i mange år |
| Din rolle | Du har tid til at træffe beslutninger undervejs | Du har brug for en projektleder der styrer forløbet for dig |
Hører dit projekt mest hjemme i midterkolonnen, er én udvikler som regel det enkleste valg. Ligger du i højre kolonne på bare én af de tre første rækker, så læs afsnittet om hvornår et team er nødvendigt. Vil du først have overblik over de forskellige roller, kan du starte med min oversigt over typer af udviklere og hvad de laver.
Hvad en fullstack-udvikler dækker, og hvad der ligger udenfor
En fullstack-udvikler arbejder i alle lag af en webløsning. Frontend er det brugeren ser og klikker på i browseren. Backend er logikken bag: brugere og rettigheder, beregninger, betalinger og de regler der gælder i netop din forretning. Dertil kommer databasen, integrationer til andre systemer via API'er og arbejdet med at sætte løsningen i drift på en server.
I praksis er de fleste fullstack-udviklere stærkest i den ene ende, så spørg ind til hvilken. Selv arbejder jeg med Laravel og PHP på backend og React, Next.js og Tailwind CSS på frontend. Vil du vide mere om den ene halvdel, har jeg skrevet om hvad en Laravel-udvikler laver i et projekt.
Det er lige så vigtigt at vide hvad der typisk ligger uden for rollen:
- Visuel identitet og grafisk design. En fullstack-udvikler kan bygge en pæn og brugbar brugerflade ud fra et designsystem, men et logo og et brand er en anden faglighed.
- Brugerresearch. Interviews og test med rigtige brugere før der bygges noget er et fag for sig.
- Native apps. Apps til iPhone og Android bygget i Swift og Kotlin kræver som regel en specialist.
- Tekster og markedsføring: indhold, SEO-strategi og annoncer.
- Døgnvagt. Én person kan ikke love svar klokken tre om natten hele året.
Det betyder ikke at projektet er for stort til én udvikler hvis du har brug for en af delene. Det betyder at den del skal løses et andet sted, mens fullstack-udvikleren står for resten.
Hvorfor én udvikler ofte er det hurtigste valg
Det lyder måske bagvendt, men flere udviklere gør ikke automatisk et projekt hurtigere. Hver gang du tilføjer en person, kommer der flere kommunikationslinjer. To personer har én linje imellem sig. Tre personer har tre, fem har ti, og otte har 28. Hver linje betyder møder, beskeder, misforståelser og ventetid.
Med én udvikler forsvinder det meste af det. Den samme person beslutter hvordan data gemmes, hvordan API'et ser ud, og hvordan knappen opfører sig. Der er ingen overdragelse fra backend til frontend, og ingen der venter på at en kollega bliver færdig. Når du ringer med en ændring, taler du med den person der skal lave den.
Det påvirker også kvaliteten. Fejl opstår ofte i overgangene mellem lag og mellem personer, fx når frontend forventer et felt som backend har kaldt noget andet. Når én person har hele billedet, bliver løsningen typisk mere sammenhængende.
Det kan også mærkes på økonomien. I et team betaler du også for koordineringen: projektledelse, statusmøder og den tid det tager at holde alle opdateret. Vil du sammenligne de forskellige måder at betale for udvikling på, har jeg samlet det i et indlæg om hvad en udvikler koster som ansat, freelancer eller bureau.
Ulempen er lige så enkel. Én person har et begrænset antal timer. Du kan ikke købe dig til at blive dobbelt så hurtigt færdig, og når udvikleren holder ferie, står projektet stille.
Hvornår du har brug for et team
Her er de situationer hvor jeg selv vil anbefale dig at vælge noget andet end én udvikler:
- Du har en lanceringsdato der ikke kan flyttes, og estimatet viser mere arbejde end én person kan nå inden da. Så skal arbejdet deles op og laves parallelt.
- Du skal bruge flere produkter på én gang, fx en webapp, en app til iPhone og Android og et administrationssystem, der alle skal være klar samme dag.
- Design er en stor del af opgaven. Skal du både have ny visuel identitet, brugerresearch og en ny platform, kræver det flere fagligheder. Mit indlæg om hvem du skal starte med, designer eller udvikler handler om netop den rækkefølge.
- Produktet kræver specialviden ud over almindelig webudvikling, fx egne maskinlæringsmodeller, tunge regulatoriske krav eller meget store datamængder.
- Nogen skal kunne reagere på nedbrud døgnet rundt. Det kræver en vagtordning med flere personer.
- Softwaren er din forretning, og der skal udvikles på den hver dag i mange år. Så er det ofte bedre at opbygge et internt team, eventuelt med en freelancer som hjælp i starten.
Har du brug for flere fagligheder på én gang, men ikke i mange år, kan et bureau være det rigtige. Min ærlige sammenligning af freelancer og bureau går i dybden med det valg.
Genkender du kun dit projekt i ét af punkterne, er løsningen ikke nødvendigvis et helt team. Ofte er det nok at én udvikler står for selve løsningen, mens en designer eller en specialist tager sig af den del der ligger udenfor.
Sådan tester du om dit projekt passer til én udvikler
Brug de seks trin her før du beslutter dig. De tager en time eller to, og du får et bedre grundlag for samtalen med en udvikler, også hvis du ender med at vælge en anden end mig.
- Beskriv kernen i én sætning. "En portal hvor vores kunder kan se ordrer og fakturaer" er en kerne. Kan du ikke beskrive projektet uden at bruge ordet "og" fem gange, er det måske flere projekter.
- Tæl platforme og integrationer. Hvor skal løsningen køre (browser, mobil eller begge), og hvilke systemer skal den tale med? Hver integration til fx et økonomisystem eller en betalingsløsning er en opgave i sig selv.
- Regn tidsplanen baglæns. Min tommelfingerregel er at en fuldtidsudvikler groft regnet har 100-130 effektive udviklingstimer om måneden når møder, mails og test er trukket fra. Viser et estimat 600 timer, og skal du lancere om to måneder, er én person ikke nok.
- Afklar designet. Har du skitser fra en designer, et eksisterende designsystem, eller er det udvikleren der skal finde på udseendet? Det sidste fungerer fint til interne værktøjer og første versioner, men ikke hvis brandet er afgørende for salget.
- Beslut hvem der har ansvaret efter lanceringen. Skal løsningen holdes opdateret og videreudvikles i roligt tempo, eller skal nogen kunne rykke ud om natten?
- Vurder hvad det koster dig hvis projektet står stille i to uger. Er svaret "ikke ret meget", passer én udvikler fint. Er svaret "vi mister kunder hver dag", skal du have en plan for afløsning, eller et team.
Peger de fleste trin mod et afgrænset produkt med en realistisk tidsplan, er én fullstack-udvikler sandsynligvis den korteste vej til en færdig løsning.
Sådan undgår du at blive afhængig af én person
Den største indvending mod én udvikler er risikoen. Hvad sker der hvis personen bliver syg, stopper eller ikke længere har tid? Det er en reel risiko, men den kan styres med få aftaler fra første dag:
- Koden skal ligge i et repository (kodearkiv) som du ejer, fx en GitHub-organisation i din virksomheds navn. Udvikleren får adgang hos dig, ikke omvendt.
- Domæne, hosting, betalingsløsning og andre konti skal være oprettet i dit navn og betalt af dig.
- Dokumentationen skal skrives løbende: hvordan løsningen sættes op, hvordan den udgives, og hvorfor de vigtigste valg blev truffet.
- Vælg et udbredt framework frem for noget eksotisk. Jo flere udviklere der kender teknologien, jo lettere er det at finde en afløser.
- Aftal hvordan en overdragelse foregår, før du får brug for den.
Med de fem ting på plads er risikoen ved én freelancer ikke væsentligt større end ved én fastansat udvikler, som også kan blive syg eller sige op. Forskellen ligger mere i hvor tæt samarbejdet er. Om du vil have en leverandør der løser opgaver, eller en der tager medansvar for produktet, har jeg skrevet om i indlægget om teknisk partner eller leverandør.
Sådan arbejder jeg når jeg er eneste udvikler
Min egen model bygger på at én person har ansvaret for hele løsningen, fra den første afklaring til driften bagefter. Det betyder i praksis:
- Du taler direkte med mig, altså den person der skriver koden. Der er ingen mellemled.
- Større projekter starter med et betalt forprojekt til fast pris, hvor jeg sammen med dig afklarer omfang, risici og pris før der skrives kode.
- Koden er din fra første dag og ligger i dit repository.
- Priserne er gennemsigtige, og du får svar inden for én arbejdsdag.
Forprojektet er også stedet hvor grænserne fra afsnittene ovenfor bliver tydelige. Viser det sig at opgaven kræver en designer, en app-specialist eller flere udviklere på samme tid, er det bedre at vide det før projektet starter end midt i det.
Næste skridt
Er én fullstack-udvikler nok til dit projekt?
- Kernen kan beskrives i én sætning.
- Tidsplanen holder med groft regnet 100-130 udviklingstimer om måneden fra én person.
- Platformene er få, typisk en webløsning der også virker på mobilen.
- Designet er enkelt, eller det kommer fra en designer.
- Driften kræver ikke døgnvagt.
- Adgangene til kode, hosting og domæne ligger hos dig.
- Du har tid til at træffe beslutninger undervejs.
Kan du krydse de fleste af, er én udvikler sandsynligvis den enkleste vej frem. Mangler du to eller flere, så overvej om dele af opgaven skal ligge hos en designer, et bureau eller et internt team. På siden om hvad jeg bygger som freelance fullstack-udvikler kan du se hvilke typer projekter jeg tager på mig.
Ofte stillede spørgsmål
Hvor stort et projekt kan én fullstack-udvikler klare?
Der er ingen fast grænse, men min tommelfingerregel er at en første version bør kunne bygges af én person på 2-4 måneder. Er projektet større, så del det op i faser og få den første i drift tidligt. Størrelsen afgøres sjældent af antallet af skærmbilleder, men af antallet af integrationer, særregler og platforme.
Kan én udvikler også bygge apps til iPhone og Android?
Det afhænger af hvilken slags app du har brug for. Mange behov kan dækkes af en webapp der fungerer godt på mobilen, og den kan en fullstack-udvikler sagtens bygge. Skal appen ligge i App Store og Google Play, kan nogle fullstack-udviklere bruge cross-platform-værktøjer som React Native, mens fuldt native udvikling typisk kræver en specialist.
Er én fullstack-udvikler billigere end en frontend- og en backend-udvikler?
Ofte ja, men sjældent fordi timeprisen er lavere. Besparelsen kommer fra færre overdragelser, færre møder og mindre koordinering. Timeprisen afhænger mere af erfaring end af titel. Til gengæld kan to specialister arbejde parallelt. Er tidsplanen stram, kan to personer derfor godt være den billigste løsning når du regner prisen for en forsinket lancering med.
Kan jeg starte med én udvikler og bygge et team senere?
Ja, og det er en almindelig vej for nye produkter. Det kræver at fundamentet er bygget til det: et udbredt framework, automatiske tests, dokumentation og en fast måde at udgive kode på. Bed den første udvikler om at have det for øje fra start og om at hjælpe nye udviklere ind i koden når den tid kommer.