15 red flags når du hyrer en udvikler, og hvad de kan koste dig

De alvorligste red flags når du hyrer en udvikler, handler sjældent om programmeringssprog. De handler om aftaler og ejerskab: ingen skriftlig kontrakt, kode der ligger på udviklerens egen konto, ingen tests og en pris hvor du ikke kan se hvad der ikke er med. Herunder får du 15 advarselstegn, hvad hvert af dem typisk ender med at koste dig, og hvad du skal bede om i stedet.

Jeg er selv freelanceudvikler og har altså en interesse i emnet. Listen er skrevet så du også kan holde den op mod mig.

Den korte version: alle 15 på én side

Min tommelfingerregel: Ét af de fem ja-punkter der ikke bliver rettet før start, er nok til at takke nej. Et enkelt af de andre kan have en god forklaring, så spørg. Ser du tre eller flere hos den samme udvikler, så vælg en anden, også selv om hvert svar lyder rimeligt for sig.

Listen passer til det trin hvor du har talt med et par kandidater. Er du ikke nået så langt, så start med min komplette guide til at hyre en udvikler. Vil du afdække punkterne på et møde, har jeg samlet 27 spørgsmål du kan stille en udvikler før du hyrer.

Første kontakt: advarselstegn før du har et tilbud

1. Langsomme eller vage svar før du har skrevet under

Før kontrakten er underskrevet, er du den kunde udvikleren gerne vil vinde. Går der en uge mellem svarene allerede nu, eller svarer mailene ikke på det du spurgte om, ved du hvordan samarbejdet bliver.

Hvad det kan koste: Ventetid i hvert led af projektet. Et spørgsmål der tager fem dage at få svar på, kan stoppe arbejdet i fem dage.

Bed om i stedet: En konkret svartid og en fast kanal til akutte fejl. Mit eget løfte er svar inden for én hverdag. Du skal ikke kræve præcis det tal, men du skal have et tal.

2. Udvikleren stiller ingen spørgsmål og siger ja til alt

En god udvikler vil på første møde vide hvem brugerne er, hvordan opgaven bliver løst i dag, og hvad der skal være klar til lanceringen. Får du i stedet et ja til hver idé uden opfølgende spørgsmål, er opgaven ikke forstået endnu.

Hvad det kan koste: Et system der løser det problem udvikleren forestillede sig, ikke dit. Og den der aldrig modsiger dig i salgsfasen, gør det næppe senere når pengene er ved at slippe op.

Bed om i stedet: Et forslag til hvad der kan vente til version to. Det viser at udvikleren tænker på dit budget.

3. Du kan ikke møde den der skriver koden

Du taler med en sælger eller en projektleder, men når du spørger hvem der skal programmere, bliver svaret "teamet". Nogle gange er opgaven solgt videre til en underleverandør uden at du får det at vide. Underleverandører er ikke et problem i sig selv, men skjulte underleverandører er.

Hvad det kan koste: Hver besked går gennem et ekstra led, og detaljer forsvinder på vejen. Dine data og din kode ender hos folk du ikke har en aftale med.

Bed om i stedet: Navnet på den eller dem der skriver koden, og et kort møde med dem før du skriver under. Bruges der underleverandører, skal det stå i kontrakten.

4. Der er intet du kan se eller tjekke

Porteføljen er flotte skærmbilleder, alle projekter er "under tavshedspligt", og der er ingen tidligere kunder du kan ringe til. Tavshedspligt er reel på enkelte projekter, men sjældent på dem alle.

Hvad det kan koste: Du opdager først niveauet når du har betalt for de første måneders arbejde.

Bed om i stedet: Et projekt du selv kan prøve, en ærlig beskrivelse af udviklerens egen rolle og to tidligere kunder du må kontakte. Hvad du skal spørge dem om, står i mine ni spørgsmål til en udviklers referencer.

5. Du bliver presset til en hurtig beslutning

Rabatten gælder kun til fredag, eller der er "en anden kunde der gerne vil have pladsen". Gode udviklere har ofte travlt, men de presser dig ikke.

Hvad det kan koste: Pres virker fordi det får dig til at droppe referencer, kontrakt og sammenligning med andre tilbud. Det er netop de tjek der fanger resten af denne liste.

Bed om i stedet: Tid til at læse kontrakten og tale med referencer. Har udvikleren reelt kun plads fra en bestemt dato, kan det siges uden at blive et ultimatum.

Pris og tilbud: når tallet ikke hænger sammen

6. En fast pris efter ti minutter

Du har beskrevet projektet løst på et kort opkald, og dagen efter kommer der en fast pris uden et eneste opfølgende spørgsmål. Fast pris er fint til en veldefineret opgave, men ingen kan prissætte et projekt de ikke kender.

Hvad det kan koste: Enten er der lagt en stor buffer på, så du betaler for usikkerheden. Eller også bliver alt der ikke stod i den korte beskrivelse, til en tillægsregning.

Bed om i stedet: Et interval og en forklaring på hvor usikkerheden ligger. Ved større projekter er et kort, betalt forprojekt den mest pålidelige vej til en fast pris du kan budgettere efter. Det er sådan jeg selv starter større opgaver, så tag det med i betragtning.

7. Prisen er uklar, eller "alt er med"

Tilbuddet er et samlet beløb uden en linje om hvad det dækker. Spørger du til hosting, licenser eller drift efter lanceringen, er svaret at det hele er med.

Hvad det kan koste: Regningerne kommer senere. Typisk drejer det sig om hosting, betalingsløsning, mailudsendelse, betalte API'er, tekster, billeder og løbende sikkerhedsopdateringer.

Bed om i stedet: En liste over hvad prisen ikke dækker, og et groft skøn over de faste udgifter pr. måned. En udvikler der kan lave den liste på stående fod, har prøvet det før.

8. Prisen er langt under de andre tilbud

Ligger to tilbud omkring 150.000 kr. og det tredje på 40.000 kr., er der en grund. Nogle gange er den god: udvikleren har bygget noget lignende og kan genbruge meget. Oftere er noget skåret fra uden at det står i tilbuddet.

Hvad det kan koste: Typisk er det tests, sikkerhed, dokumentation eller tid til afklaring der forsvinder. Det mærker du ikke ved lanceringen, men når de første ændringer skal laves, eller når en anden udvikler skal overtage.

Bed om i stedet: En forklaring på forskellen, punkt for punkt. Bed alle tilbudsgivere om at beskrive det samme: skærme og funktioner, integrationer, test og hvad der sker efter lanceringen. Så bliver forskellen synlig.

9. Udvikleren vil have hele beløbet forud

En forudbetaling ved opstart er normalt, især hos freelancere der reserverer tid i kalenderen til dig. Hele beløbet før der er skrevet en linje kode, er noget andet.

Hvad det kan koste: Du har intet at forhandle med hvis kvaliteten skuffer, tidsplanen skrider eller udvikleren forsvinder.

Bed om i stedet: Betaling efter milepæle du kan se og afprøve, eller månedlig fakturering med en oversigt over timer og opgaver. Det her er et af de fem punkter hvor jeg ville takke nej hvis det ikke bliver ændret.

Kontrakt og ejerskab: de advarselstegn der bliver dyrest

10. Der er ingen skriftlig kontrakt

Aftalen er et tilbud på mail og et "det finder vi ud af". Problemerne opstår når I er uenige om hvad der var med, hvad en ændring koster, eller hvad der sker hvis I stopper.

Hvad det kan koste: Ud over uenighed om omfang er der ophavsretten. Når en ansat skriver et program som en del af jobbet, overgår rettighederne til arbejdsgiveren efter ophavsretslovens § 59. Den regel gælder ikke for en freelancer. Uden en aftale der overdrager rettighederne, er det ikke givet at koden er din, selv om du har betalt for den.

Bed om i stedet: En kontrakt der dækker omfang, ændringer, betaling, rettigheder, adgange og opsigelse. Ændringer skal prissættes og godkendes skriftligt før der bliver arbejdet på dem. Jeg har gennemgået de 14 punkter en kontrakt med en freelanceudvikler bør indeholde. Ved større projekter er en time hos en advokat godt givet ud.

11. Koden ligger på udviklerens egen konto

Koden ligger i et repository (kodearkiv) på udviklerens GitHub- eller GitLab-konto, og du får den "når projektet er færdigt" eller "når alt er betalt". Det lyder harmløst indtil I bliver uenige.

Hvad det kan koste: Udvikleren har din kode som pant. Vil du skifte, er du afhængig af den du vil væk fra. Forsvinder udvikleren, kan du stå uden den nyeste version. Står du allerede der, så læs hvordan du skifter udvikler midt i et projekt uden at miste arbejdet.

Bed om i stedet: Et repository oprettet på virksomhedens egen konto fra første dag, hvor udvikleren får adgang som bruger. Det tager få minutter at sætte op. Sådan arbejder jeg selv: koden er kundens fra dag ét.

12. Domæne, hosting og konti står i udviklerens navn

Det samme gælder alt omkring koden: domænet, serveren, betalingsløsningen, mailtjenesten og de API-nøgler systemet bruger. Er de oprettet i udviklerens navn og betalt med udviklerens kort, er det i praksis udviklerens system.

Hvad det kan koste: Ved en konflikt eller en glemt betaling kan siden gå ned, og et domæne kan være besværligt at få flyttet. Selv i et godt samarbejde skal du spørge om lov for at give en anden adgang.

Bed om i stedet: At alle konti oprettes i virksomhedens navn med en fælles mailadresse som ejer, og at udvikleren får brugeradgang. En samlet oversigt over konti og adgange skal være en del af afleveringen.

Måden der bygges på: problemer du først mærker senere

13. Ingen tests og intet testmiljø

Spørger du hvordan udvikleren sikrer at tingene virker, er svaret "jeg tester det selv". Der er ingen automatiske tests og intet testmiljø (staging), så ændringer går direkte ud til dine brugere. Til en lille hjemmeside kan det være fint. Til et system din forretning afhænger af, er det ikke.

Hvad det kan koste: Hver ny funktion kan ødelægge noget der virkede før, fx login eller betaling, og det er en kunde der finder fejlen. Med tiden tager hver ændring længere tid, fordi ingen tør røre koden.

Bed om i stedet: Automatiske tests af de dele der ikke må gå i stykker, og et testmiljø hvor du selv kan afprøve ændringer før de sættes i drift. Hvad du ellers skal kigge efter, har jeg samlet i tegn på en sund kodebase.

14. Du ser først noget ved afleveringen

Planen er at du får hele systemet at se når det er færdigt om fire måneder. Indtil da får du statusmails om at det går fint.

Hvad det kan koste: Misforståelser bliver opdaget på det tidspunkt hvor de er dyrest at rette. En knap der sidder forkert, er let at flytte. En forkert forståelse af hvordan dine ordrer bliver behandlet, kan betyde at store dele skal laves om.

Bed om i stedet: Adgang til testmiljøet fra de første uger og en kort demo hver eller hver anden uge, hvor du ser noget der virker og ikke bare en præsentation.

15. Systemet bygger på noget kun udvikleren kender

Udvikleren har sit eget framework, sit eget CMS eller en sjælden teknologi som få andre arbejder med. Det kan være dygtigt lavet, men det binder dig til én person.

Hvad det kan koste: Når udvikleren er syg, har for travlt eller stopper, kan ingen andre overtage uden at bruge lang tid på at sætte sig ind i det. I værste fald skal systemet bygges om.

Bed om i stedet: En begrundelse der handler om dit projekt og ikke om udviklerens vaner. Udbredte frameworks som Laravel, React og Next.js gør det lettere at finde en anden udvikler senere. Det er dem jeg selv arbejder med, så jeg er ikke helt neutral.

Advarselstegn der ofte er gode tegn

Nogle ting kan ligne red flags, men peger tit den anden vej:

• Udvikleren fraråder en funktion eller foreslår at den venter. Det sparer dig penge.
• Der kommer et betalt forprojekt før den faste pris. Det er prisen for et estimat der holder, og jeg arbejder selv sådan.
• Der er en mindre forudbetaling ved opstart. Det er normalt. Det er hele beløbet forud der er problemet.
• Udvikleren siger "det ved jeg ikke, jeg vender tilbage". Det er bedre end et selvsikkert gæt.
• Udvikleren er ikke den billigste. Prisen alene siger ikke meget om kvalitet, hverken op eller ned.
• Udvikleren fortæller åbent at der bruges AI-værktøjer. Det er skjult brug uden menneskelig gennemgang der giver grund til bekymring.

Sådan reagerer du når du ser et red flag

Et red flag behøver ikke afslutte samtalen. Sådan anbefaler jeg at du griber det an:

1. Spørg direkte. Sig hvad du har set, og hvorfor det bekymrer dig. En god udvikler bliver ikke fornærmet.
2. Få rettelsen på skrift. Et mundtligt "det kan vi godt" er ikke nok når det gælder ejerskab, adgange og betaling.
3. Læg mærke til reaktionen. Bliver udvikleren defensiv, eller forklarer vedkommende længe uden at ændre noget, er det et svar i sig selv.
4. Vælg en anden hvis et af de fem afgørende punkter ikke bliver rettet. To ekstra uger på at finde en anden er billigere end at skifte udvikler midt i et projekt.

Næste skridt: brug listen før du skriver under

Gå listen igennem for hver kandidat lige efter det sidste møde. Sæt kryds ved de punkter du har set, og skriv udviklerens forklaring ved siden af. Så sammenligner du på noget konkret og ikke på en mavefornemmelse.

Listen kan også vise at du slet ikke skal hyre en freelancer som mig. Skal en udvikler være fast del af dit team i årevis, er det ofte billigere og mere stabilt at ansætte. Har du brug for design, tekster og udvikling i én samlet pakke, er et bureau tit et bedre match. Vil du se hvilke opgaver jeg tager, og hvordan jeg arbejder med kontrakt, kode og adgange, så kig på mine ydelser som freelanceudvikler.

Ofte stillede spørgsmål

Hvad gør jeg hvis jeg opdager et red flag efter projektet er gået i gang?+

Start med ejerskabet. Bed om at få koden flyttet til et repository på din egen konto og få domæne, hosting og andre konti overført til virksomhedens navn. Få derefter en skriftlig aftale på plads om resten af projektet. Det er lettest mens samarbejdet stadig fungerer, så vent ikke til der opstår en konflikt.

Gælder de samme red flags for et bureau?+

Ja, langt de fleste gør. Hos bureauer er det især værd at tjekke hvem der faktisk skriver koden, og om løsningen bygger på bureauets eget CMS eller system som andre ikke kan arbejde videre på. Hele beløbet forud er sjældnere, men spørg alligevel til betalingsplanen og til hvem der ejer koden.

Hvor stor en forudbetaling er rimelig?+

Der er ingen fast norm, men min tommelfingerregel er at forudbetalingen højst bør dække det første stykke arbejde du kan se resultatet af, fx den første milepæl eller et forprojekt. Resten bør betales efterhånden som du får noget du kan afprøve. Så er risikoen fordelt nogenlunde ligeligt mellem dig og udvikleren.

Er det et red flag hvis udvikleren ikke vil skrive under på en NDA?+

Ikke nødvendigvis. Mange udviklere er tøvende over for brede fortrolighedsaftaler før de overhovedet kender projektet, fordi de kan begrænse dem i andre opgaver. En kort, gensidig aftale er rimelig når du deler forretningshemmeligheder eller kundedata. Afviser udvikleren også den, er det værd at spørge hvorfor.