Freelancer vs fastansat udvikler: hvad passer til din virksomhed?

Freelancer vs fastansat udvikler handler mindre om timepris end om to spørgsmål: hvor stabilt er dit behov for udvikling, og hvem skal lede arbejdet? En fastansat udvikler er det rigtige valg når softwaren er en fast del af din forretning hele året og når du har nogen der kan lede en udvikler. En freelancer passer bedre når behovet svinger, når opgaven er klart afgrænset, eller når du endnu ikke ved hvor meget udvikling du får brug for.

Jeg er selv freelancer, så læs med det forbehold. Jeg har forsøgt at være lige så tydelig om hvornår du bør ansætte i stedet for at hyre en som mig.

Den korte version: freelancer eller fastansat?

Min beslutningsregel er enkel. Skal der udvikles på fuld tid i mindst et par år, og har du nogen der kan lede en udvikler, så overvej en ansættelse. Mangler en af de to ting, så start med en freelancer. Er du i tvivl om hvilken slags udvikler opgaven overhovedet kræver, så begynd med oversigten over 12 typer udviklere.

Fleksibilitet: hvor stabilt er dit behov?

De fleste softwareprojekter har ikke et jævnt behov. Der er en periode hvor der bygges meget, typisk op til lanceringen af en første version. Bagefter kommer en lang periode med rettelser, små forbedringer og sikkerhedsopdateringer, som måske kræver en dag eller to om måneden. Så kommer den næste store funktion, og behovet stiger igen.

En freelancer passer til den kurve. Du kan få fuld fart på i tre måneder og bagefter nøjes med en fast aftale om vedligehold. En fastansat er fast kapacitet: 37 timer om ugen, uanset om der er nok at bygge. I stille perioder finder virksomheden typisk andre opgaver til udvikleren. Det kan være fornuftigt, men det kan også betyde at en dyr specialist bruger tiden på noget en anden kunne have løst.

Fleksibiliteten gælder også når samarbejdet skal stoppe. Er udvikleren funktionær, hvad udviklere typisk er, skal du efter funktionærlovens § 2 give mindst 1 måneds varsel i de første seks måneder og derefter 3 måneder. Varslet stiger med en måned for hvert tredje ansættelsesår, dog højst til seks måneder. Har I aftalt prøvetid, kan du i de første tre måneder opsige med 14 dages varsel. En freelanceaftale kan I selv indrette, og varslet er som regel kortere.

Bagsiden er at fleksibiliteten går begge veje. En freelancer har andre kunder. Har I ikke aftalt et fast antal timer eller dage, kan du ikke regne med at vedkommende har tid præcis når du får en idé. Har du brug for at nogen kan rykke ud samme dag, så skriv det ind i aftalen, eller overvej om behovet i virkeligheden er et job.

Ledelse: hvem skal styre arbejdet?

Det er den faktor jeg oftest ser undervurderet. En udvikler skriver ikke god kode i et tomrum. Nogen skal beslutte hvad der skal bygges, i hvilken rækkefølge, og hvornår noget er godt nok.

Når du ansætter

Ansætter du en udvikler, påtager du dig også at lede et menneske. Det betyder introduktion til koden og forretningen, løbende prioritering, sparring, lønsamtaler og en plan for hvordan udvikleren bliver dygtigere. Gode udviklere vil gerne lære af nogen, så et job som den eneste tekniske person i huset er sværere at besætte.

Kan ingen i virksomheden vurdere teknisk kvalitet, bliver det svært allerede ved ansættelsen. Hvordan ved du om kandidaten er dygtig, og hvordan opdager du om koden bliver sværere og sværere at ændre? Det gælder især hvis du overvejer en nyuddannet. En junior uden en erfaren kollega at spørge er en risiko for både dig og vedkommende. Forskellen har jeg beskrevet i junior, medior eller senior udvikler.

Når du hyrer en freelancer

Med en freelancer styrer du opgaven, ikke personen. I aftaler hvad der skal laves, i hvilken rækkefølge og hvordan der leveres, og en erfaren freelancer tager selv ansvaret for de tekniske valg. Du skal stadig have én person der kan træffe beslutninger og svare på spørgsmål. Uden den går arbejdet i stå, uanset model.

Mangler du teknisk ledelse mere end du mangler hænder, er en ansættelse sjældent det første skridt. Så kan en teknisk chef på deltid (fractional CTO) være et bedre sted at starte, fx til at lægge en plan og vurdere kandidater.

Videnstab: hvad sker der når udvikleren stopper?

En almindelig grund til at ansætte er at få viden ind i huset. Det er et godt argument, men kun halvt rigtigt. En fastansat udvikler opbygger forretningsforståelse hver dag, og den viden er din så længe vedkommende bliver. Når personen stopper, går viden ud ad døren, præcis som med en freelancer.

Og det kan gå hurtigt. Efter samme lov kan en funktionær selv sige op med 1 måneds varsel til udgangen af en måned, medmindre I har aftalt noget andet. Du kan altså være bundet af op til seks måneders varsel, mens din eneste udvikler kan være væk efter godt en måned. Har du kun én udvikler, er du afhængig af én person i begge modeller. Forskellen er at den ene står på din lønliste.

Freelanceren har en anden risiko: vedkommende kan få travlt hos andre kunder eller vælge at stoppe samarbejdet. Til gengæld er det lettere at gøre overdragelse til en del af aftalen fra start fordi begge parter ved at samarbejdet har en ende.

Sådan beskytter du dig, uanset model

• Koden ligger i et repository (kodearkiv) som virksomheden ejer, ikke på udviklerens private konto.
• Du har selv administratoradgang til hosting, domæne, database og alle tredjepartstjenester.
• Vigtige beslutninger skrives ned, fx hvorfor systemet er bygget som det er, og hvordan det sættes i drift.
• Kontrakten siger tydeligt at rettighederne til koden tilhører dig.
• Mindst én anden person, intern eller ekstern, har set koden og kan træde til.

Det sidste punkt er det sværeste for små virksomheder. En lille løbende aftale med en ekstern udvikler kan være en billig forsikring, også selvom du har en fastansat.

Hvornår hver model ikke passer

Her er de situationer hvor jeg vil fraråde hver af de to modeller, også min egen.

Ansæt ikke en udvikler hvis

• Du har brug for udvikling i et halvt år og ikke ved hvad der skal ske bagefter.
• Ingen i virksomheden har tid eller indsigt til at lede en udvikler.
• Opgaven kræver en specialist til én del, fx en integration eller en opgradering af et ældre system, som ikke fylder et helt år.
• Du skal i gang inden for få uger. En ansættelse bliver sjældent klar i tide.

Vælg ikke en freelancer hvis

• Softwaren er dit produkt, og der skal udvikles på fuld tid i mange år. Så betaler du for fleksibilitet du ikke bruger, og viden bygges op uden for huset.
• Du har brug for en der deltager i hverdagen: kundemøder, support, planlægning og fællesskabet på arbejdspladsen.
• Du leder efter en person der på sigt kan blive teknisk leder og ansætte et team.
• Du har brug for at nogen er til stede hver dag eller har vagt, og ikke vil betale for at få det skrevet ind i en aftale.

Kombinationen: freelancer først, ansættelse bagefter

Valget er ikke altid enten-eller, og det behøver ikke være permanent. Til virksomheder der bygger et nyt produkt, anbefaler jeg typisk denne rækkefølge:

1. En freelancer bygger første version. Du får noget at teste på rigtige brugere uden at binde dig til en løn før du ved om produktet holder.
2. Koden dokumenteres løbende. Så har din kommende ansatte noget solidt at overtage.
3. Freelanceren hjælper med ansættelsen. En udvikler der kender koden, kan stille kandidaterne de rigtige tekniske spørgsmål og vurdere svarene.
4. I har en periode med overlap. Den nye udvikler og freelanceren arbejder sammen i nogle uger, så viden flytter fra person til person og ikke kun fra dokument til person.
5. Freelanceren bliver ekstra kapacitet. Når den ansatte har overtaget, kan freelanceren træde til i travle perioder, under ferie eller på opgaver der kræver en bestemt specialviden.

Rækkefølgen kan også gå den anden vej. Har du allerede et internt team, kan en freelancer dække en specialistopgave eller en travl periode uden at du skal ansætte nogen.

Det der får kombinationen til at virke, er relationen. En freelancer der tænker som en partner, er interesseret i at overdragelsen lykkes frem for at gøre sig uundværlig. Forskellen har jeg skrevet om i teknisk partner vs leverandør. Og overvejer du et bureau som tredje mulighed, har jeg sammenlignet det med en freelancer i freelance vs bureau.

Næste skridt: fem spørgsmål før du vælger

Kan du svare på spørgsmålene, ved du som regel også hvad du skal vælge. Kan du ikke, har du sandsynligvis brug for en kort afklaring af projektet først. På siden om hvad jeg hjælper virksomheder med kan du se hvilke slags projekter jeg tager, fra hjemmesider og platforme til SaaS og videreudvikling af eksisterende systemer.

Ofte stillede spørgsmål

Kan jeg have en freelancer på fuld tid i flere år?+

Det kan du, men vær opmærksom på grænsen til et ansættelsesforhold. Arbejder freelanceren kun for dig, efter dine instruktioner og på faste arbejdstider i lang tid, kan Skattestyrelsen vurdere vedkommende som lønmodtager. Det kan få konsekvenser for skat og moms for begge parter. Har du brug for én person på fuld tid i årevis, er en ansættelse ofte det ærlige svar. Spørg din revisor hvis du er i tvivl.

Hvem ejer koden når en ansat eller en freelancer skriver den?+

Skriver en ansat koden som en del af sit arbejde, overgår ophavsretten til dig som arbejdsgiver efter ophavsretslovens § 59. Den regel gælder ikke for en freelancer, som derfor beholder rettighederne indtil kontrakten overdrager dem til dig. Sørg for at aftalen siger det tydeligt. Det er ikke juridisk rådgivning, så få kontrakten læst af en advokat hvis der står meget på spil.

Hvor langt opsigelsesvarsel skal jeg aftale med en freelancer?+

Til en løbende aftale anbefaler jeg typisk en til tre måneder. Det giver dig tid til at finde en afløser og freelanceren tid til at planlægge. Et længere varsel binder jer begge uden at gøre overdragelsen bedre. Det vigtigste er at aftalen også beskriver hvad der skal afleveres ved ophør: kode, adgange, dokumentation og eventuelt et par timers introduktion til den næste udvikler.

Kan jeg prøve en udvikler af som freelancer før jeg ansætter?+

Ja, men sig det fra start. Nogle freelancere er åbne for en ansættelse mens mange har valgt at være selvstændige og ikke ønsker et job. En kort, betalt opgave er stadig en god måde at se hvordan en udvikler arbejder, kommunikerer og dokumenterer. Leder du efter en fremtidig medarbejder, så nævn det ved første samtale så I ikke spilder hinandens tid.