27 spørgsmål til en udvikler før du hyrer: gode svar og advarselstegn

De vigtigste spørgsmål til en udvikler handler om hvem der skriver koden, hvordan du ser fremskridt undervejs, hvad prisen dækker og hvem der ejer resultatet. Programmeringssprog fylder mindre end mange tror. Herunder får du 27 spørgsmål du kan stille på et første møde, og til hvert af dem hvordan et godt svar lyder, og hvilket advarselstegn du skal lytte efter.

Jeg er selv freelanceudvikler, så det er spørgsmål jeg bliver stillet. Læs med det forbehold, og brug gerne listen på mig.

Den korte version: fem spørgsmål hvis du kun har 20 minutter

Stil spørgsmålene på et møde eller et videoopkald i stedet for at sende dem som et skema. Hvordan udvikleren svarer, siger lige så meget som selve svaret: Bliver det konkret, eller glider det over i generelle vendinger?

Spørgsmålene virker over for både freelancere og bureauer, og svarene hjælper dig også med at afgøre om du skal vælge en freelancer eller et bureau. Er du helt i starten, så begynd med min guide til at hyre en udvikler, og kom tilbage hertil når du har to-tre kandidater.

Erfaring og match

1. Hvem skal skrive koden?

Hos et bureau kan sælgeren, projektlederen og udvikleren være tre forskellige personer, og nogle freelancere sender opgaver videre til underleverandører. Det er ikke forkert i sig selv, men du skal vide det.

Godt svar: Navnet på den eller de personer der skriver koden, og et tilbud om at møde dem. Bruges der underleverandører, bliver det sagt uden at du skal spørge to gange. Mit eget svar er kort: det er mig, og det er også mig du taler med.

Advarselstegn: Svaret er "vores team", og du møder aldrig andre end sælgeren.

2. Hvad har du lavet der ligner mit projekt, og hvad var din rolle?

Godt svar: Et konkret projekt, gerne et du kan se eller prøve, og en ærlig beskrivelse af hvad udvikleren selv lavede og hvad andre stod for.

Advarselstegn: Flotte skærmbilleder uden forklaring, eller en rolle der bliver mere og mere uklar jo mere du spørger ind.

3. Hvad var det sværeste ved det projekt?

Spørgsmålet skiller dem der har lavet arbejdet, fra dem der har læst om det.

Godt svar: Et konkret problem, fx en integration der ikke virkede som dokumentationen lovede, og hvad udvikleren ville gøre anderledes i dag.

Advarselstegn: "Det gik egentlig fint det hele." Sådan går projekter næsten aldrig.

4. Hvilken teknologi vil du bruge, og hvorfor passer den til mit projekt?

De fleste udviklere har en fast værktøjskasse, og det er sådan man bliver god. Det er begrundelsen du skal lytte efter.

Godt svar: Valget bliver knyttet til dit projekt: vedligehold, hosting og hvor let det er at finde en anden udvikler senere. Udbredte frameworks som Laravel, React og Next.js gør dig mindre afhængig af én person. Jeg arbejder selv med netop dem, så tag min anbefaling med det forbehold.

Advarselstegn: Et hjemmelavet system som kun udvikleren selv kender, eller et svar fyldt med fagord som ikke bliver forklaret når du spørger.

5. Hvad ville du fraråde mig at bygge?

Godt svar: Et forslag om at skære noget fra i første version, eller at bruge en færdig løsning til en del af opgaven. Det viser at udvikleren tænker på din forretning og dit budget.

Advarselstegn: Ja til alt. En udvikler der aldrig siger nej på det første møde, siger sjældent til når budgettet er ved at løbe løbsk.

6. Må jeg tale med to tidligere kunder?

Godt svar: Ja, med navne og kontaktoplysninger inden for få dage. Hvad du skal spørge dem om, har jeg samlet i 9 spørgsmål til en udviklers tidligere kunder.

Advarselstegn: Kun anbefalinger på hjemmesiden, eller tavshedspligt som forklaring på samtlige projekter.

Proces og samarbejde

7. Hvordan ser de første to uger ud?

Godt svar: En konkret plan: opstartsmøde, adgange til de systemer der skal bruges, afklaring af de første opgaver og noget du kan se og afprøve inden for kort tid.

Advarselstegn: "Vi går bare i gang." Uden en plan for starten er der sjældent en plan for resten.

8. Hvor ofte ser jeg noget der virker?

Godt svar: Løbende adgang til et testmiljø (staging) hvor du selv kan klikke rundt, og en kort gennemgang hver eller hver anden uge.

Advarselstegn: Du ser først resultatet ved afleveringen. Så opdager du misforståelserne på det tidspunkt hvor de er dyrest at rette.

9. Hvor hurtigt svarer du, og hvad gør jeg når noget haster?

Godt svar: En konkret svartid og en aftalt kanal til akutte fejl. Jeg svarer selv inden for én hverdag. Det er den slags konkrete løfter du skal kigge efter.

Advarselstegn: "Jeg er altid tilgængelig." Det holder ikke ret længe, og det betyder som regel at der ikke er nogen aftale.

10. Hvor mange projekter har du samtidig?

Godt svar: Et ærligt tal og en forklaring på hvordan tiden bliver fordelt, fx faste dage om ugen til dit projekt.

Advarselstegn: Et undvigende svar. Så risikerer du at få de timer der er tilbage når de andre kunder er tilfredse.

11. Hvad har du brug for fra mig?

Godt svar: En liste: én person der kan træffe beslutninger, tekster og indhold, adgang til eksisterende systemer og svar på spørgsmål inden for et aftalt antal dage.

Advarselstegn: "Ingenting, jeg klarer det hele." Så kommer udvikleren til at gætte sig til hvordan din forretning fungerer.

12. Hvordan håndterer du ændringer undervejs?

Ændringer kommer i alle projekter. Det afgørende er om der er en fast måde at håndtere dem på.

Godt svar: Ændringen bliver beskrevet, prissat og godkendt skriftligt før der bliver arbejdet på den.

Advarselstegn: "Det finder vi ud af." Det ender typisk med en overraskende regning eller en uenighed om hvad der var aftalt.

13. Hvad gør du hvis noget tager længere tid end planlagt?

Godt svar: Udvikleren siger det så snart det står klart, og kommer med muligheder: skære noget fra, flytte en deadline eller udvide budgettet.

Advarselstegn: Det er aldrig sket. Så har udvikleren enten lavet meget få projekter, eller også fortæller vedkommende ikke hele historien.

Pris, estimat og kontrakt

14. Fast pris eller timepris, og hvorfor til netop mit projekt?

Godt svar: En begrundelse. Fast pris passer til en veldefineret opgave, timepris til løbende udvikling hvor indholdet ændrer sig. Mange kombinerer de to: fast pris på en afgrænset fase og timepris bagefter.

Advarselstegn: En fast pris på et stort projekt efter en halv times snak og ingen opfølgende spørgsmål. Enten er der lagt en stor buffer på, eller også bliver hver afvigelse til en tillægsregning.

15. Hvad er ikke med i prisen?

Godt svar: En konkret liste: hosting, licenser, betalingsløsning og andre tredjepartstjenester, tekster og billeder, samt drift og vedligehold efter lanceringen.

Advarselstegn: "Alt er med." Det er det aldrig.

16. Hvor sikkert er dit estimat?

Godt svar: Et interval frem for ét tal og en forklaring på hvor usikkerheden ligger. Ved større projekter også et forslag om et kort, betalt forprojekt der gør estimatet til noget du kan budgettere efter. Sådan arbejder jeg selv: større projekter starter med et forprojekt til fast pris.

Advarselstegn: Et præcist beløb ned til kronen på et projekt der kun er beskrevet løst.

17. Hvornår og hvordan fakturerer du?

Godt svar: Faste milepæle eller månedlig fakturering med en oversigt over timer og opgaver. En mindre forudbetaling ved opstart er ikke usædvanlig.

Advarselstegn: Hele beløbet forud, eller fakturaer der ikke specificerer hvad du betaler for.

18. Hvad sker der hvis vi stopper halvvejs?

Godt svar: Du betaler for det udførte arbejde og får kode, dokumentation og adgange med det samme. Der er et rimeligt opsigelsesvarsel, og det står i kontrakten. Tjeklisten til en kontrakt med en freelanceudvikler viser hvad den ellers skal indeholde.

Advarselstegn: Ingen skriftlig aftale, eller koden bliver holdt tilbage indtil hele projektet er betalt.

19. Er du forsikret hvis noget går galt?

Ikke alle små opgaver kræver det, men er løsningen forretningskritisk eller håndterer den betalinger, er det et rimeligt spørgsmål.

Godt svar: Udvikleren ved hvilken ansvarsforsikring der er tegnet (typisk en professionel ansvarsforsikring), hvad den dækker, og kan sende dokumentation.

Advarselstegn: Udvikleren har aldrig tænkt over det eller bliver irriteret over spørgsmålet.

Kode, kvalitet og ejerskab

20. Hvem ejer koden, og hvor ligger den?

Godt svar: Du ejer den, og den ligger i dit eget repository (kodearkiv), fx på GitHub, fra første dag. Udvikleren har adgang, men det er dig der har nøglerne. Sådan arbejder jeg selv, og det skal også stå i kontrakten.

Advarselstegn: Koden ligger på udviklerens egen konto og bliver "overdraget når projektet er færdigt".

21. Hvordan tester du at det virker?

Godt svar: Automatiske tests af de vigtigste dele, fx login og betaling, og et testmiljø hvor ændringer bliver afprøvet før de sættes i drift. Omfanget skal passe til budgettet, og udvikleren kan forklare hvorfor.

Advarselstegn: "Jeg klikker det selv igennem" om et system som din forretning afhænger af.

22. Hvordan dokumenterer du så en anden kan overtage?

Godt svar: En vejledning i at sætte projektet op, en kort beskrivelse af de vigtigste beslutninger og alle adgange samlet ét sted.

Advarselstegn: "Koden dokumenterer sig selv." Ren kode hjælper, men den fortæller ikke hvorfor tingene er som de er eller hvor serveren står.

23. Hvordan håndterer du sikkerhed og persondata?

Godt svar: Konkrete svar om opdateringer, adgangsstyring, backup og hvor data ligger. Behandler udvikleren persondata på dine vegne, skal I have en databehandleraftale, og det er dit ansvar som dataansvarlig ifølge Datatilsynet at den bliver lavet.

Advarselstegn: "Det tager hostingen sig af."

24. Bruger du AI-værktøjer, og hvordan sikrer du kvaliteten?

Godt svar: Åbenhed om hvilke værktøjer der bruges, at al kode bliver gennemgået af et menneske før den sættes i drift, og at dine fortrolige data ikke ryger ind i værktøjerne uden en aftale.

Advarselstegn: Udvikleren kan ikke forklare koden der bliver afleveret. AI-værktøjer er fine, men den der afleverer koden, skal kunne stå inde for den.

Efter lanceringen

25. Hvad sker der den første måned efter lanceringen?

Godt svar: En aftalt periode hvor fejl bliver rettet, overvågning af fejl og nedetid, og en plan for de første justeringer.

Advarselstegn: "Så er det færdigt." Den første måned med rigtige brugere afslører næsten altid noget der skal rettes.

26. Hvad koster drift og vedligehold om året?

Godt svar: Et groft interval og en forklaring på hvad det dækker: hosting, sikkerhedsopdateringer, overvågning og mindre rettelser. Gerne som en fast månedlig aftale, så du ikke skal have et nyt tilbud hver gang.

Advarselstegn: "Det kører bare." Frameworks og de pakker koden bygger på, skal opdateres løbende, ellers opstår der sikkerhedshuller.

27. Hvordan foregår en overdragelse hvis jeg vil videre med en anden?

Godt svar: Et roligt svar om adgange, dokumentation og et møde med den nye udvikler. Står du allerede i den situation, kan du læse hvordan du skifter udvikler midt i et projekt.

Advarselstegn: Udvikleren bliver defensiv. En god udvikler indretter arbejdet så du kan gå videre når du vil.

Næste skridt: fra svar til valg

Alle 27 spørgsmål på ét møde er for meget. Sådan bruger du listen i praksis:

1. Vælg de 10-15 spørgsmål der betyder mest for dit projekt, og start med de fem fra tabellen øverst.
2. Stil de samme spørgsmål til to-tre kandidater, og skriv svarene ned lige efter hvert møde.
3. Bed om de vigtigste svar på skrift: pris, hvad der ikke er med, ejerskab af koden og opsigelse.
4. Ring til referencerne før du skriver under.

De svar der bør få dig til at takke nej, har jeg samlet i 15 red flags når du hyrer en udvikler.

Svarene kan også vise at du slet ikke skal hyre en som mig. Har du brug for en udvikler på fuld tid i flere år, er en ansættelse bedre. Skal design, tekst og udvikling ske på samme tid, er et bureau ofte det rigtige valg. Vil du se hvilke opgaver jeg selv tager og hvordan jeg griber dem an, så kig på oversigten over mine ydelser.

Ofte stillede spørgsmål

Hvor mange udviklere bør jeg tale med før jeg vælger?+

To til tre er typisk nok. Med færre har du intet at sammenligne med, og med flere bliver det svært at huske hvem der sagde hvad. Er opgaven lille, fx en enkelt integration eller nogle rettelser, kan én grundig samtale og et tjek af referencer være nok, så udvælgelsen ikke tager længere tid end selve opgaven.

Skal jeg sende spørgsmålene til udvikleren før mødet?+

Send hellere en kort beskrivelse af projektet end hele listen. Spørgsmålene virker bedst mundtligt fordi du hører om svarene er konkrete eller indøvede. En beskrivelse på en side eller to gør til gengæld mødet mere konkret: udvikleren kan forberede spørgsmål til netop din opgave, og de spørgsmål siger også noget om erfaringen.

Hvad gør jeg hvis jeg ikke forstår de tekniske svar?+

Bed udvikleren forklare det igen med almindelige ord. En god udvikler kan forklare teknologivalg, test og sikkerhed uden fagsprog, og det er i sig selv et godt tegn. Er projektet stort, kan du betale en uafhængig udvikler for et par timers vurdering af tilbuddene. Det er billigt i forhold til at vælge forkert.

Hvad gør jeg hvis to udviklere svarer lige godt?+

Vælg den du har lettest ved at tale med og som stillede de bedste spørgsmål til dit projekt. I skal arbejde sammen i måneder, så kommunikation vejer tungt. Er du stadig i tvivl, kan en lille betalt prøveopgave på et par dage vise hvordan samarbejdet fungerer i praksis før du binder dig til hele projektet.