Sådan hyrer du en udvikler: den komplette guide for virksomheder og founders

Når du skal hyre en udvikler, er det sjældent selve valget af person der går galt. Det er forarbejdet der svigter: et uklart behov, den forkerte model og en aftale hvor ingen har tænkt over hvem der ejer koden. Den sikre vej er at afklare opgaven, vælge mellem freelancer, bureau og fastansat ud fra den og først derefter finde kandidater, vurdere dem på rigtigt arbejde og skrive en kontrakt der giver dig koden og adgangene.

Jeg er selv freelance udvikler og ikke en broker, så jeg tjener ikke penge på at formidle andre. Jeg har dog en interesse i at du vælger en som mig, så læs med det forbehold. Jeg skriver lige så tydeligt hvornår du bør vælge noget andet.

Den korte version: ni trin fra behov til samarbejde

Her er hele forløbet samlet ét sted. Resten af guiden går i dybden med hvert trin og henviser til mere detaljerede guides undervejs.

På et mindre projekt kan trin 3-6 klares på et par uger. Det er især trin 1, 2 og 8 der bliver sprunget over, og det er dem der er dyrest at rette bagefter. Skal du kun have løst en opgave på 10-50 timer, kan du gøre flere af trinene kortere. Det har jeg beskrevet i guiden om at bruge en freelance udvikler til mindre opgaver.

Før du leder: afklar opgaven og vælg model

Trin 1: Beskriv hvad du vil have løst

Den vigtigste forberedelse koster ikke andet end et par timer. Skriv en kort projektbeskrivelse før du kontakter nogen. Den behøver ikke være teknisk, og 1-2 sider er nok. Den skal svare på fem ting:

1. Hvilket problem skal løses, og for hvem? Beskriv brugerne og den arbejdsgang der skal blive bedre.
2. Hvad skal være færdigt først? Den mindste version der kan bruges i praksis, ikke drømmeversionen.
3. Hvad findes i forvejen? Systemer, data og integrationer (forbindelser til andre systemer) som løsningen skal arbejde sammen med.
4. Hvilken ramme har du? Et budgetinterval og en deadline, og hvorfor deadlinen ligger der.
5. Hvem træffer beslutningerne hos dig, og hvor meget tid har vedkommende til projektet?

Uden en beskrivelse får du tilbud der ikke kan sammenlignes. Én udvikler prissætter en enkel første version, en anden et færdigt system med alle tænkelige funktioner, og forskellen på de to tal siger intet om hvem der er billigst. Brug gerne min skabelon til en projektbeskrivelse som udgangspunkt.

Er du ikke selv teknisk, så beskriv forretningen og arbejdsgangene, ikke teknologien. Valget af framework og hosting er udviklerens opgave at foreslå og din opgave at få forklaret. Jeg har skrevet en hel guide om at hyre en udvikler uden teknisk viden.

Trin 2: Vælg den model der passer til opgaven

Når du ved hvad opgaven er, kan du vælge hvem der skal løse den. Valget afgør hvor du leder, hvad du betaler, og hvilke risici du skal styre. Min korte beslutningsregel:

• Vælg en freelancer når opgaven er klart afgrænset: en første version af et produkt (en MVP), en kundeportal, en integration eller løbende videreudvikling af et system der allerede kører. Du taler direkte med den der skriver koden, men du er afhængig af én person.
• Vælg et bureau når design, tekst, brugerresearch og udvikling skal ske i de samme uger. Du får et helt hold og én kontrakt, og du betaler for bureauets drift.
• Ansæt selv når softwaren er selve din forretning, og der skal udvikles på den hver dag i mange år. Regn med at rekrutteringen tager måneder.
• Find en teknisk medstifter når du bygger en startup og har brug for en partner der deler risikoen. Du betaler med ejerandele i stedet for honorar.

Den fulde sammenligning af pris, risiko og kvalitet står i freelancer vs bureau. Overvejer du en partner frem for en leverandør, så læs om teknisk medstifter, og hvornår en freelancer er bedre. Mange gode forløb blander i øvrigt modellerne: en freelancer bygger første version og hjælper bagefter din første fastansatte udvikler i gang.

Hvornår du ikke skal hyre en freelancer som mig

Jeg tjener penge på at blive hyret, så det her afsnit er måske det vigtigste i guiden. Du skal vælge noget andet:

• Når standardsoftware dækker det meste af behovet. Et bookingsystem, en webshop eller et CRM-system findes færdigt til en brøkdel af prisen. Byg kun selv når standardløsningen tvinger dig til at ændre en arbejdsgang der er en del af din konkurrencefordel.
• Når du skal bruge et helt hold på én gang, fx til en ny visuel identitet, nye tekster og en ny platform i samme kvartal.
• Når udvikling er en fuldtidsopgave i mange år. Så betaler du for en fleksibilitet du aldrig bruger.
• Når ingen hos dig har tid til at svare på spørgsmål og træffe beslutninger. Det går galt uanset hvem du hyrer.
• Når opgaven kræver en specialist i en teknologi jeg ikke arbejder med. Jeg arbejder primært med Laravel, PHP og moderne JavaScript som React og Next.js.

Find og vurder kandidater

Trin 3: Led de steder hvor gode udviklere faktisk er

Min tommelfingerregel er at starte med anbefalinger. En udvikler der har lavet godt arbejde for en du stoler på, har allerede bestået den sværeste test: at levere til en rigtig kunde. Spørg i dit netværk, hos din revisor og hos virksomheder der har fået bygget noget der ligner det du har brug for.

Giver netværket ikke nok, er der fire andre veje:

• LinkedIn og faglige netværk, hvor du kan se hvad folk har arbejdet på, og hvem I kender i fællesskab.
• Freelanceplatforme, hvor du hurtigt får mange navne, men selv skal sortere hårdt. De passer bedst til afgrænsede opgaver.
• Brokers og konsulentnetværk, der finder kandidaten og står for kontrakten. Betalingen for det ligger typisk i timeprisen, så spørg hvor stor en del der går til formidleren.
• Udviklerens egen hjemmeside og blog, hvor du kan se hvordan vedkommende tænker og forklarer før I har talt sammen.

Jeg har samlet de bedste steder at finde en udvikler i en særskilt guide, sammenlignet de store freelanceplatforme og forklaret hvad du betaler for hos brokers og konsulentnetværk. Målet med trinnet er 3-5 relevante navne, ikke 30.

Trin 4: Vurder tidligere arbejde og stil de rigtige spørgsmål

Et CV fortæller hvad en udvikler har været med til. Tidligere projekter fortæller hvad vedkommende kan. Bed om at se 2-3 løsninger der minder om din, og spørg ind til dem:

• Hvad var din rolle helt konkret, og hvad lavede andre?
• Hvad var det sværeste ved projektet, og hvordan løste du det?
• Kører løsningen stadig, og hvem vedligeholder den i dag?
• Hvad ville du gøre anderledes hvis du startede forfra?

Du behøver ikke kunne læse kode for at bruge svarene. Læg mærke til om udvikleren kan forklare tekniske valg i et sprog du forstår, og om svarene handler om kundens forretning eller kun om teknologien. Sådan kommer I til at tale sammen i månedsvis. I guiden om at vurdere en udviklers portfolio uden at kunne kode går jeg mere i dybden, og jeg har samlet 27 spørgsmål du kan stille før du hyrer.

Hold også øje med advarselstegnene. En udvikler der lover alt uden at stille spørgsmål, sender en fast pris efter ti minutter eller ikke vil lægge koden i dit repository, er et dårligt tegn. Den fulde liste står i red flags når du hyrer en udvikler.

Trin 5: Tal med tidligere kunder

Referencer er det trin flest springer over, og det er det billigste at gennemføre. Bed om to kunder fra projekter der ligner dit, gerne én hvor samarbejdet er afsluttet. Et kvarter i telefonen med hver er nok.

Spørg ikke kun om kunden var tilfreds. Spørg hvad der skete da noget gik galt, for det gør det i alle projekter. Blev deadlines holdt, og hvis ikke, fik kunden besked i god tid? Hvordan var det at ændre noget undervejs? Ville de hyre udvikleren igen til et lignende projekt? Jeg har samlet ni spørgsmål til en udviklers tidligere kunder med forklaring på hvad svarene fortæller dig.

Test samarbejdet og aftal prisen

Trin 6: Start med en lille, betalt opgave

En samtale viser hvordan nogen præsenterer sig. En rigtig opgave viser hvordan de arbejder. Før du sætter et større projekt i gang, er det fornuftigt at starte med noget lille og afgrænset som du betaler for.

Før større projekter starter jeg selv med et betalt forprojekt til fast pris. Et forprojekt afklarer opgaven og de største tekniske risici, og resultatet er en plan og et estimat du kan budgettere efter. Sørg for at resultatet er dit, også hvis du vælger en anden til at bygge løsningen. Det er den bedste måde jeg kender til at teste et samarbejde, fordi du ser hvordan udvikleren spørger, prioriterer og skriver før du har bundet dig til noget stort.

Ubetalte prøveopgaver anbefaler jeg ikke. Erfarne udviklere siger ofte nej til dem, så du risikerer at sortere de bedste fra, og en opgave der kan løses på en aften, siger alligevel ikke meget om et projekt på flere måneder. Fordele og ulemper ved de forskellige former står i guiden om prøveopgaver og betalte testforløb.

Trin 7: Sammenlign tilbud og aftal prisen

Der er tre almindelige måder at prissætte udvikling på:

• Fast pris på et afgrænset projekt. Du kender prisen på forhånd, men ændringer undervejs skal aftales og prissættes for sig.
• Timepris på løbende udvikling, gerne med et loft pr. måned, så budgettet ikke løber løbsk.
• En fast månedlig aftale om vedligehold, så sikkerhedsopdateringer og små rettelser bliver lavet uden et nyt tilbud hver gang.

Når du sammenligner tilbud, så se efter hvad der står, og hvad der ikke står. Er test, dokumentation, opsætning af hosting og projektledelse med? Hvad sker der efter lanceringen? Hvilke antagelser bygger prisen på? Et tilbud der er markant lavere end de andre, har som regel udeladt noget. Det kan være fint så længe du ved hvad.

Vil du have prisen ned, så forhandl om indholdet og ikke om timeprisen. Skær funktioner fra første version og gem dem til senere. Så får du en lavere pris uden at presse udvikleren til at springe test og kvalitet over. Jeg har skrevet om at forhandle med en udvikler uden at ende med dårligere kvalitet, og på min prisside kan du se hvordan jeg prissætter, før du skriver.

Kontrakt, kode og adgange

Trin 8 er det der beskytter dig hvis samarbejdet slutter, uanset om det slutter godt eller skidt. Det kedelige papirarbejde er her vigtigere end prisen.

Det skal kontrakten indeholde

Et tilbud med en underskrift er ikke en kontrakt. Sørg for at aftalen mindst dækker:

• Rettighederne til koden. Når en ansat skriver et program som led i sit arbejde, overgår ophavsretten til arbejdsgiveren efter ophavsretslovens § 59. Den regel gælder ikke for en freelancer, så aftalen skal sige udtrykkeligt at rettighederne overdrages til dig.
• Betaling og milepæle: hvad du betaler for, hvornår, og hvad der skal være færdigt før hver betaling.
• Ændringer: hvordan nye ønsker bliver estimeret og godkendt før der bliver arbejdet på dem.
• Fejlretning efter levering: hvor længe og på hvilke vilkår.
• Opsigelse og overdragelse: hvad du får udleveret og hvordan hvis en af parterne stopper.
• Fortrolighed hvis du deler forretningshemmeligheder. Det kan stå i kontrakten eller i en separat fortrolighedsaftale (NDA).
• En databehandleraftale hvis udvikleren får adgang til persondata, fx i din database. Så er der typisk tale om et databehandlerforhold, som Datatilsynet beskriver i vejledningen om rollefordelingen mellem dataansvarlig og databehandler.

Det her er ikke juridisk rådgivning. Står der meget på spil, så få en advokat til at læse kontrakten igennem. Jeg har lavet en tjekliste med 14 punkter til kontrakten med en freelance udvikler og skrevet om hvornår en NDA med en udvikler er nødvendig.

Adgange der skal stå i dit navn

Kontrakten giver dig rettighederne på papiret. Adgangene giver dig dem i praksis. Disse ting skal oprettes i din virksomheds navn, og udvikleren skal inviteres som bruger:

• Repository, fx på GitHub eller GitLab.
• Hosting og servere.
• Domæner og DNS.
• Tredjepartstjenester som betaling, e-mailudsendelse og statistik.

Hos mig ejer kunden koden fra første dag, og det bør du kræve af alle du hyrer. Jeg går i dybden med det i guiderne om hvem der ejer koden, og hvilke adgange du skal sikre dig, og om hvordan du undgår at blive låst til én udvikler.

Kom godt i gang og hold samarbejdet sundt

Trin 9 begynder dagen efter kontrakten er underskrevet. De første uger sætter tonen for resten af forløbet.

De første to uger

Giv udvikleren det der skal til for at komme i gang uden at vente: adgange, testdata, en fast kontaktperson og en prioriteret liste over hvad der skal laves først. Aftal også hvad "færdig" betyder. Er en opgave færdig når koden er skrevet, eller først når den er testet og sat i drift? Min tjekliste til onboarding af en freelance udvikler har ti ting du kan have klar på dag 1.

En fast rytme

Når et projekt går skævt, er det sjældent koden alene der er problemet. Oftere er det uklare prioriteter og beslutninger der hober sig op. Tre aftaler forebygger det meste:

• Én fælles opgaveliste som både du og udvikleren arbejder ud fra.
• En kort status hver uge: hvad er lavet, hvad er det næste, og hvad venter på dig.
• En demo af software der virker, hver eller hver anden uge, så du kan reagere tidligt.

Hvordan du får møder, beskeder og forventninger til at spille sammen, står i guiden om at samarbejde med en udvikler.

Når det ikke går som planlagt

Deadlines der bliver udskudt igen og igen, svar der bliver kortere, og demoer der ikke bliver til noget, er tegn du skal tage alvorligt tidligt. Tag snakken med det samme, og spørg konkret hvad der skal til. Mange af de klassiske årsager til at IT-projekter fejler kan rettes hvis de bliver opdaget i tide.

Hjælper det ikke, er det trin 8 der redder dig. Ligger koden og adgangene hos dig, kan en ny udvikler tage over. Hvordan du gør det med mindst muligt tab, har jeg beskrevet i guiden om at skifte udvikler midt i et projekt.

Næste skridt: tjekliste før du siger ja

Brug listen som en sidste kontrol før du skriver under med en udvikler.

Kan du sætte flueben ved det hele, har du styr på de ting der oftest går galt. Vil du se hvilke opgaver jeg selv tager, fra hjemmesider og webplatforme til SaaS og vedligehold, så står de på siden med mine ydelser.

Ofte stillede spørgsmål

Hvor lang tid tager det at hyre en udvikler?+

Med en freelancer går der typisk et par uger fra første kontakt til opstart, afhængigt af hvornår udvikleren har plads i kalenderen. Et forprojekt kan ofte starte hurtigere end selve udviklingen. Skal du ansætte, tager rekrutteringen ofte flere måneder, og derefter kommer kandidatens opsigelsesperiode fra det nuværende job oveni.

Skal jeg vælge en udvikler i Danmark eller i udlandet?+

Det afhænger af hvor meget koordinering du selv kan klare. En udvikler i udlandet kan have en lavere timepris, men tidszoner, sprog og aftaler efter et andet lands regler gør samarbejdet sværere at styre. Er du ikke selv teknisk, er en udvikler du kan mødes med og ringe til i din arbejdstid, ofte billigere målt på det samlede resultat.

Hvad gør jeg hvis jeg ikke selv kan vurdere kvaliteten af koden?+

Køb en uafhængig gennemgang. En anden erfaren udvikler kan på få timer gennemgå koden ved en milepæl og fortælle dig om der er åbenlyse problemer med struktur, sikkerhed eller test. Det koster lidt i forhold til projektet og giver dig et grundlag for at stille de rigtige spørgsmål før problemerne bliver dyre.

Kan jeg hyre en udvikler til bare et par timer om måneden?+

Ja, mange freelancere har små faste aftaler om vedligehold og mindre rettelser. Det passer godt til en løsning der allerede kører og skal holdes opdateret. Regn med at mange har et minimum pr. måned fordi selv små opgaver kræver at man sætter sig ind i koden igen. Aftal også hvor hurtigt du kan forvente svar når noget haster.

Hvornår skal jeg gå fra freelancer til fastansat udvikler?+

Når der er arbejde til en person på fuld tid hver uge, og du kan se flere år frem. Indtil da er en freelancer typisk billigere og mere fleksibel. Et godt skifte bliver planlagt: bed freelanceren om løbende dokumentation, og brug vedkommende til at vurdere kandidater og sætte den nye medarbejder ind i koden.