Sådan hyrer du en udvikler når du ikke selv er teknisk

Du kan sagtens hyre en udvikler selvom du ikke er teknisk, så længe du holder fast i de beslutninger der er dine og låner teknisk dømmekraft til resten. Du ejer problemet, prioriteterne, budgettet og adgangene. Teknologivalg, estimater og kodekvalitet får du vurderet af en uafhængig udvikler før du skriver under og igen undervejs.

Jeg er selv freelanceudvikler, så læs med det forbehold at jeg har en interesse i hvem du vælger. Guiden siger også tydeligt hvornår en som mig ikke er svaret.

Den korte version: hvad du beslutter, og hvad du låner

Reglen er enkel: alt der handler om din forretning, beslutter du, og alt der kræver at man kan læse kode, får du en anden til at vurdere. Hele forløbet fra behov til underskrevet kontrakt står i min guide til at hyre en udvikler. Her handler det om det der er anderledes når du ikke selv kan kode.

Din rolle: produktejer, ikke teknisk chef

Ikke-tekniske iværksættere og ledere falder typisk i en af to grøfter. Enten overlader de alt til udvikleren med et "du er jo eksperten", eller også prøver de at styre tekniske detaljer de ikke kan vurdere, fx et framework en bekendt har anbefalet. I det første tilfælde opdager du først problemerne når de er bygget ind. I det andet betaler du for en beslutning ingen kan forsvare.

Den rolle der virker, hedder produktejer. Du bestemmer hvad der bygges, i hvilken rækkefølge, og hvornår det er godt nok. Udvikleren bestemmer hvordan, men skal kunne forklare konsekvenserne i tid, penge og risiko. Fire beslutninger er dine:

1. Problemet og brugerne: hvem skal bruge løsningen, og hvad skal blive lettere for dem?
2. Prioriteterne: hvad skal med i første version, og hvad kan vente?
3. Budgettet: hvor meget vil du bruge før du stopper op og vurderer?
4. Godkendelsen: løser det leverede opgaven, eller skal der rettes?

Ingen af dem kræver at du kan kode, men de kræver tid. Min tommelfingerregel er et par timer om ugen, mere i de første uger. Har ingen hos dig den tid, går det galt uanset hvem du hyrer.

Dit vigtigste værktøj: en uafhængig vurdering

Den største ulempe ved ikke at være teknisk er at du ikke kan skelne et realistisk estimat fra et optimistisk, eller ren kode fra kode der bliver dyr at bygge videre på. Løsningen er at købe dømmekraft hos en der ikke har noget at vinde ved svaret, en såkaldt second opinion. Det er sjældent et stort beløb i forhold til selve projektet.

Hvem du kan spørge

• En udvikler i dit netværk: gratis eller billigt og fint til et hurtigt tjek af et tilbud. Vurderingen er dog sjældent grundig, og vedkommende kender måske kandidaten.
• En freelanceudvikler du betaler for et par timer: uafhængig og kan læse både estimater og kode. Aftal på forhånd at vedkommende ikke byder på opgaven, så vurderingen ikke farves af et ønske om at få den.
• En fractional CTO, altså en teknisk chef på deltid: relevant når du har brug for løbende teknisk ledelse, fx med flere udviklere. Dyrere, men dækker også strategi og ansættelser.
• Et formelt code review: en grundig gennemgang af en eksisterende kodebase med en skriftlig rapport, fx før lancering eller ved overtagelse. Jeg har beskrevet ni situationer hvor et code review udefra betaler sig.

Hvornår det betaler sig mest

1. Før du skriver under. Er estimatet realistisk? Er teknologien et udbredt valg som andre udviklere kan overtage? Hvad mangler i tilbuddet?
2. Ved første milepæl. Efter de første ugers udvikling kan en anden udvikler se om koden ligger i dit repository, om der er automatiske test, og om strukturen er til at følge.
3. Før lancering. Sikkerhed, backup, overvågning og en plan for opdateringer bagefter.

Har du kun budget til én vurdering, er første milepæl som regel det bedste tidspunkt. Der er rigtig kode at se på, og det er stadig billigt at rette kursen.

Hvad du sender, og hvad du spørger om

Send projektbeskrivelsen og tilbuddet, og senere læseadgang til repository og testmiljø. Står der fortrolighed i tilbuddet, så spørg udvikleren før du sender det videre. Stil derefter konkrete spørgsmål:

• Er estimatet realistisk for det der er beskrevet, og hvad er ikke med?
• Er teknologivalget så udbredt at en anden udvikler kan tage over?
• Hvad er de tre største risici, og hvordan ville du afprøve dem først?
• Hvis du skulle overtage projektet i morgen, hvad ville du så være bekymret for?

Bed om svaret på skrift, højst en side, prioriteret og i almindeligt sprog. Du skal vide hvad der er alvorligt, hvad der er smag og behag, og hvad du bør gøre nu.

Når de to udviklere er uenige

Det sker, og det er ikke en afstemning. Uenighed om smag, fx hvilket framework man foretrækker, betyder lidt så længe valget er udbredt. Uenighed om sikkerhed, ejerskab af data og om andre kan overtage koden betyder meget. Bed begge om at forklare uenigheden i konsekvenser: hvad koster det, hvor lang tid tager det, og hvad er risikoen hvis vi lader være? Reagerer din udvikler afvisende på en saglig gennemgang, er det i sig selv en oplysning.

Sådan hyrer du en udvikler uden teknisk viden i syv trin

Trinene følger den almindelige proces, men hvert af dem er tilpasset at du ikke selv kan læse koden.

1. Beskriv forretningen, ikke teknologien

Skriv en kort projektbeskrivelse i dit eget sprog: hvem brugerne er, hvad de gør i dag, hvad der irriterer dem, og hvad de skal kunne i første version. Skriv ikke hvilken teknologi løsningen skal bygges i medmindre der er en forretningsmæssig grund som et eksisterende system. Når udviklerne selv foreslår teknologien, kan du sammenligne hvordan de tænker.

Beskriv konkrete situationer frem for lister med funktioner. "En kunde ringer og vil flytte sin booking, og i dag finder vi den i et regneark og sender en mail i hånden" fortæller en udvikler mere end "bookingmodul med ændringsfunktion". Min skabelon til en projektbeskrivelse kan udfyldes uden et eneste fagudtryk.

2. Opret konti og adgange før du hyrer nogen

Det er langt lettere at eje sine adgange fra start end at få dem overdraget bagefter. Opret disse ting i virksomhedens navn, og invitér udvikleren som bruger når I går i gang:

• En fælles e-mailadresse til tekniske konti på dit eget domæne, fx it@. Ikke din private mail og ikke udviklerens.
• En organisation på GitHub eller GitLab til koden. En organisation på GitHub kan oprettes gratis, og du bestemmer selv hvem der har adgang til hvad.
• En konto hos hostingudbyderen, betalt med virksomhedens kort.
• Domænet, registreret i virksomhedens navn.
• En password manager med deling, fx 1Password eller Bitwarden, med en fælles boks til projektets adgangskoder.

Kan du ikke selv sætte det op, så bed udvikleren om hjælp, men på dine konti og gerne med dig ved tastaturet. Når samarbejdet en dag slutter, fjerner du én bruger i stedet for at bede om at få din egen løsning udleveret.

3. Test om udvikleren kan forklare sine valg

Du kan ikke vurdere en udviklers kode, men du kan vurdere om vedkommende kan forklare sig. Det er den vigtigste egenskab for dig, for du skal træffe beslutninger ud fra de forklaringer i månedsvis. Bed hver kandidat om tre ting på første møde:

1. Fortæl hvordan du ville bygge første version, i et sprog jeg kan følge.
2. Nævn én ting du ville fraråde mig at bygge, og hvorfor.
3. Hvad er den største risiko i mit projekt?

Lyt efter om svarene handler om din forretning, om udvikleren taler i tid, penge og risiko, og om du får spørgsmål tilbage. Fagord der aldrig bliver oversat, eller et "det er teknisk, det behøver du ikke tænke på", er advarselstegn. Bed også om et kort skriftligt resumé efter mødet. En halv side viser hvordan udvikleren vil kommunikere resten af projektet. Tidligere arbejde kan du også tjekke uden at læse kode, som beskrevet i guiden om at vurdere en udviklers portfolio.

4. Få tilbuddet vurderet før du skriver under

Send projektbeskrivelsen og tilbuddet til en uafhængig udvikler, som beskrevet ovenfor. Det kræver typisk kun få timers arbejde, og det fanger urealistiske estimater og manglende punkter før du er bundet.

5. Start med et lille, betalt forløb

Før større projekter starter jeg selv med et betalt forprojekt til fast pris. Det afklarer opgaven og de største risici, og du står med en plan og et estimat bagefter. For dig som ikke er teknisk, er det en ekstra fordel at resultatet er et dokument du kan få vurderet før der er brugt penge på selve udviklingen. Sørg for at det tilhører dig, også hvis en anden ender med at bygge løsningen. Andre måder at teste et samarbejde på står i guiden om prøveopgaver og betalte testforløb.

6. Skriv acceptkriterier ind i aftalen

Acceptkriterier er korte beskrivelser af hvornår noget er færdigt, skrevet så du selv kan afprøve dem. Et eksempel: "Når en kunde har betalt, får vedkommende en kvittering på mail inden for et minut." De giver dig en måde at sige "ikke færdig endnu" på uden at skulle argumentere teknisk.

Skriv dem ind i aftalen sammen med det grundlæggende: at rettighederne til koden overdrages til dig, at adgangene står i dit navn, og hvordan en overdragelse foregår hvis I stopper. Behandler udvikleren persondata på dine vegne, fx med adgang til kundedatabasen, er vedkommende som udgangspunkt databehandler efter GDPR, og så kræver artikel 28 en databehandleraftale. Er du i tvivl, så spørg en rådgiver. Jeg har samlet de 14 punkter kontrakten med en freelanceudvikler skal indeholde.

7. Følg fremdriften uden at læse kode

Statusmails kan alle skrive. Software der virker, kan du afprøve. Byg derfor din opfølgning op om det du kan se og klikke på:

• Et testmiljø (staging): en kopi af løsningen hvor du afprøver nye ting før dine kunder ser dem.
• En demo hver eller hver anden uge, hvor du selv klikker rundt i stedet for at se udvikleren gøre det.
• Én fælles opgaveliste, fx i Trello, Linear, Notion eller GitHub Projects, hvor hver opgave har sine acceptkriterier.
• En ugentlig status i tre linjer: hvad er lavet, hvad er det næste, og hvad venter på dig.

Har du ikke set noget der virker i en måned, så spørg hvorfor. Der kan være gode grunde, men du skal kende dem.

Ti fagord du vil møde, oversat

Du behøver ikke kunne fagsproget for at hyre godt, men det hjælper at vide hvorfor ordene betyder noget for dig.

Støder du på et ord der ikke står på listen, så spørg udvikleren. Det er en del af jobbet at forklare det.

Hvornår du ikke skal hyre en freelancer som mig

En freelanceudvikler passer godt til et afgrænset projekt eller til løbende videreudvikling af et system der allerede kører. For en ikke-teknisk iværksætter er det ikke altid det rigtige:

• Når softwaren er hele din forretning, og der skal træffes tekniske beslutninger hver uge i mange år. Så har du brug for en teknisk medstifter eller en teknisk chef, fastansat eller på deltid.
• Når flere udviklere skal arbejde sammen. Nogen skal lede dem, og det er en anden rolle end at skrive koden.
• Når et standardsystem eller et no-code-værktøj kan teste idéen først. Har du ikke vist at nogen vil bruge eller betale for løsningen, er det ofte klogere at starte der.
• Når ingen hos dig har tid til at være produktejer. Et bureau med en projektleder kan tage noget af arbejdet, men beslutningerne er stadig dine.

Jeg arbejder primært med Laravel, PHP og moderne JavaScript som React og Next.js. Kræver din opgave noget helt andet, er en specialist i den teknologi et bedre valg.

Næste skridt: er du klar til at hyre?

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

Kører din løsning allerede, og mangler du en udvikler der kan holde den opdateret, bygge videre på den og forklare hvad der sker, så kan du se hvordan jeg arbejder med vedligehold og videreudvikling. Du taler direkte med den der skriver koden, og du får svar inden for én arbejdsdag.

Ofte stillede spørgsmål

Kan jeg bruge ChatGPT eller en anden AI til at vurdere en udviklers tilbud?+

Du kan bruge en AI-assistent til at forstå begreber og formulere spørgsmål, men ikke til at afgøre om tilbuddet er godt. Den kender ikke dit projekt bedre end den tekst du giver den, og den kan lyde sikker uden at have ret. Brug den til at forberede dig til mødet med udvikleren eller til den uafhængige vurdering. Del ikke et fortroligt tilbud uden tilladelse.

Hvad koster en uafhængig vurdering af et tilbud?+

Typisk et par timers arbejde til en erfaren udviklers almindelige timepris, når det kun handler om projektbeskrivelse og tilbud. En gennemgang af en eksisterende kodebase tager længere tid og afhænger af størrelsen. Bed om en fast pris eller et loft over antal timer på forhånd, og aftal hvad du får tilbage, fx en prioriteret side med fund og anbefalinger.

Hvordan ved jeg om udvikleren bruger for mange timer?+

Bed om timeregistrering pr. opgave, så du kan sammenligne med estimatet. Afvigelser sker i alle projekter, men du skal have besked før de sker, ikke først på fakturaen. Et månedligt loft over timer giver dig et naturligt tidspunkt at stoppe op. Er du i tvivl over længere tid, så lad en anden udvikler kigge på et par af de største opgaver og vurdere om tidsforbruget er rimeligt.