Sådan hyrer du en freelance webudvikler

Når du vil hyre en freelance webudvikler, skal du først beskrive den leverance, du køber. Find derefter kandidater med relevant erfaring, gennemgå deres eget arbejde, og få en skriftlig aftale om omfang, rettigheder, betaling og aflevering, før udviklingen starter.

Et godt hyringsforløb skal ende med mere end et navn og en pris. Begge parter skal kunne forklare, hvad der skal leveres, hvordan det godkendes, og hvordan virksomheden kan drive løsningen videre efter samarbejdet.

1. Beskriv opgaven så den kan vurderes

Start med et kort opgaveoplæg, som du sender til alle kandidater. Beskriv behovet i almindeligt sprog. Du behøver ikke vælge programmeringssprog eller skrive en teknisk kravspecifikation på forhånd.

Oplægget bør indeholde følgende.

• Formålet og den vigtigste handling, brugeren skal kunne gennemføre
• Den eksisterende hjemmeside, platform og integrationer, hvis der er nogen
• De funktioner og sidetyper, der skal være med i første levering
• Det indhold, du selv leverer, og det arbejde udvikleren skal udføre
• Budgetramme, ønsket lanceringsdato og eventuelle faste afhængigheder
• Hvem der træffer beslutninger og godkender arbejdet
• Hvad der udtrykkeligt ligger uden for opgaven

Et illustrativt oplæg til en servicevirksomhed kunne være følgende.

Vi skal have en hjemmeside med forside, ydelser, cases og kontakt. Besøgende skal kunne sende en forespørgsel til vores fælles indbakke og få en tydelig kvittering på skærmen. Vi leverer godkendte tekster og billeder. Tilbuddet skal dække opsætning, mobilvisning, formular, aftalte SEO-opgaver, test og overdragelse. Booking, login og oversættelse er ikke med. Angiv, hvilke oplysninger du mangler for at vurdere pris og leveringstid.

Tilføj konkrete acceptkriterier. For kontaktformularen kan det være, at gyldige oplysninger når den aftalte indbakke, manglende felter giver forståelige fejlbeskeder, og formularen kan bruges med tastatur på de aftalte enheder. Aftal testdata og modtager, så testen ikke sender uvedkommende personoplysninger eller forstyrrer kunder.

Hvis opgaven gælder en eksisterende løsning, skal kandidaten også kende dens begrænsninger. Beskriv adgang til kode, kendte fejl og dokumentation. Giv først den nødvendige adgang, når rammerne for gennemgangen er aftalt.

2. Find kandidater der passer til arbejdet

Du kan finde freelancere gennem relevante anbefalinger, faglige netværk, direkte søgning og freelanceplatforme. En anbefaling er et udgangspunkt for screening, ikke en erstatning for den. Spørg, hvilken opgave personen løste, og om den ligner din.

Se efter erfaring med den konkrete opgavetype. En specialist i opsætning af en webshop og en udvikler af kundeportaler kan begge være dygtige, men de løser forskellige problemer. En enkel standardside kan klares af en platformspecialist eller med en eksisterende skabelon. Du behøver ikke købe specialudvikling, hvis standardfunktioner dækker behovet.

Når du kontakter en kandidat, så send oplægget og bed om svar på relevant erfaring, mulig opstart, forventet arbejdsform og de vigtigste ubekendte. Lav en kort liste over kandidater, som faktisk passer til opgaven og har plads til den. En lang liste giver mere koordination uden nødvendigvis at forbedre beslutningen.

Hvis du stadig er i tvivl om, hvorvidt én person kan dække opgaven, så læs sammenligningen af freelance webudvikler og webbureau, før du går videre.

3. Kontrollér cases og kandidatens egen rolle

Bed kandidaten gennemgå et relevant projekt. Spørg, hvad personen selv byggede, hvilke dele andre stod for, og hvad der blev afleveret. En portfolio med et flot website dokumenterer ikke i sig selv ansvar for design, backend, test eller drift.

Brug disse spørgsmål i gennemgangen.

• Hvilket problem skulle projektet løse, og hvilke begrænsninger var der?
• Hvad var dit eget ansvar fra opstart til aflevering?
• Hvilken vanskelig beslutning tog du, og hvorfor?
• Hvordan blev løsningen testet, og hvad fik kunden ved overdragelsen?
• Hvad ville du ændre, hvis opgaven skulle løses igen?

Åbn gerne den viste løsning, men husk, at kunden kan have ændret den siden leveringen. Send ikke beskeder eller ordrer gennem andres websites som en del af din screening.

Ved et større eller kritisk projekt er en relevant reference nyttig. Aftal kontakten med kandidaten, og spørg referencen om samarbejde, ændringer, aflevering og håndtering af fejl. Bed ikke om fortrolige projektoplysninger. Hvis kandidaten ikke må vise kode eller navngive en kunde, kan en anonymiseret gennemgang eller et eget demonstrationsprojekt være et alternativ.

4. Stil tekniske spørgsmål med et praktisk formål

Du skal vurdere, om kandidaten kan tage ansvar for opgaven. En quiz i programmeringssprog hjælper sjældent en ikke-teknisk køber med det. Bed i stedet om en forklaring af, hvad der skal ske i din løsning.

Hvad vil du bruge standardfunktioner til, og hvad skal bygges særskilt? Et brugbart svar forbinder teknologivalget med behov, vedligeholdelse og begrænsninger. En liste over værktøjer er ikke nok.

Hvordan tester du den vigtigste brugerrejse, også når noget fejler? Bed om et eksempel fra dit oplæg. Ved en formular bør svaret omfatte både levering af beskeden, ugyldige oplysninger og fejl hos en tilknyttet tjeneste.

Hvordan arbejder du på en eksisterende løsning uden at afbryde driften? Spørg til testmiljø, backup, lancering og mulighed for at vende tilbage til den tidligere version. Den konkrete plan skal passe til platformen og risikoen.

Hvordan beskytter du adgange og personoplysninger? Se efter afgrænset adgang, separate brugere og en plan for testdata. Delte administratorlogins og en kopi af hele kundedatabasen bør ikke være standardløsningen til en lille ændring.

Hvordan kan en anden udvikler overtage? Bed om en beskrivelse af kode, dokumentation, licenser og konti, som følger med. For en lukket platform skal kandidaten forklare, hvad der kan eksporteres, og hvad der kræver en ny løsning.

Hvad gør du ved sygdom eller en forsinkelse? Aftal, hvordan du får besked, hvad der er tilgængeligt af igangværende arbejde, og om andre kan hjælpe. Lov ikke dig selv kontinuitet alene på baggrund af kandidatens tilgængelighed i dag.

Hvis du køber en teknisk kompleks løsning, som du ikke selv kan vurdere, kan en uafhængig fagperson gennemgå tilbud og arkitektur. Hold gennemgangen afgrænset til projektets væsentlige risici.

5. Brug en betalt afklaring når usikkerheden er stor

En mindre, betalt første opgave er relevant, når kandidatens arbejdsform eller en teknisk ubekendt skal afprøves, før hele projektet bestilles. Det kan være en gennemgang af en eksisterende integration med en skriftlig anbefaling, kendte begrænsninger og et forslag til næste etape.

Aftal også her leverance, pris eller timeloft, rettigheder og stopkriterium. Afklaringen skal give noget, du kan bruge, selv om kandidaten ikke får hovedopgaven. Undgå at bede flere freelancere bygge brugbar projektkode gratis for at konkurrere om kontrakten.

En prøveopgave er ikke nødvendig ved enhver lille hjemmeside. Hvis oplægget er klart, cases er relevante, og aftalen er gennemskuelig, kan en ekstra etape blot gøre processen længere.

6. Få aftale, betaling og rettigheder på skrift

Før opstart skal tilbuddet omsættes til en aftale, som begge parter accepterer. Saml mindst disse punkter.

• Leverancer, fravalg, kundens materiale og acceptkriterier
• Milepæle, feedbackfrister og håndtering af forsinkelser
• Pris, momsforhold, betalingsfrister og tredjepartsudgifter
• Godkendelse af ændringer og deres effekt på pris og tid
• Kildekode, brugsrettigheder, licenser og tidspunkt for overdragelse
• Test, lancering, fejlrettelse og eventuel efterfølgende support
• Fortrolighed, eventuelle underleverandører og ansvar for persondata
• Opsigelse, betaling for igangværende arbejde og aflevering ved stop

Ved et afgrænset projekt kan betaling knyttes til en opstartsbetaling, en demonstreret milepæl og den aftalte slutlevering. Det er et forslag til struktur, ikke en standardfordeling. Aftal beløb, dokumentation og godkendelsesfrist for hver etape. Ved timebetaling bør du aftale rapportering, budgetloft og ny godkendelse, før loftet overskrides. Læs mere om valget mellem fast pris og timepris på webprojekter.

Hvem ejer koden?

Skeln mellem at modtage kildekoden, at have adgang til den og at have juridiske rettigheder til at bruge og ændre den. I Danmark siger ophavsretslovens § 53, stk. 2, at overdragelse af eksemplarer ikke omfatter overdragelse af ophavsretten. At få en kopi af kode er derfor ikke det samme som at få ophavsretten. Se ophavsretslovens regler om overdragelse.

Aftal, hvilke rettigheder du får til den specialudviklede del, om en anden leverandør må ændre den, og hvornår rettighederne træder i kraft. Få eksisterende komponenter, open source, billeder, skrifttyper og betalte plugins beskrevet særskilt. De kan have egne licenser og kan ikke uden videre behandles som kundeejet kode.

Bed også om den praktiske overdragelse. Et kodearkiv uden opsætningsvejledning, nødvendige konfigurationer og adgang til relevante tjenester er ikke nok til at drive løsningen videre. Få juridisk hjælp til rettigheds- og ansvarsvilkår, hvis deres betydning overstiger det, du selv kan vurdere.

Hvad med personoplysninger?

Afklar rollen, før udvikleren får adgang til persondata. Datatilsynet skelner mellem behandling på dine vegne og situationer, hvor en ekstern person blot kan få adgang som led i en anden opgave. En freelancer er derfor ikke automatisk databehandler alene på grund af mulig adgang. Hvis samarbejdet indebærer databehandling på virksomhedens vegne, skal det relevante aftalegrundlag være på plads. Se Datatilsynets vejledning om rollefordeling.

Hvad koster en freelance webudvikler?

Prisen afhænger af den konkrete leverance, afklaringsbehovet og betalingsmodellen. Bed om et tilbud på samme oplæg, og få udvikling, licenser, hosting og support adskilt, så du kan sammenligne den samlede udgift. Guiden om hvad en hjemmeside til en lille virksomhed koster går videre med prisdrivere og sammenligning af tilbud.

7. Følg arbejdet og kontrollér afleveringen

Aftal korte statuspunkter med en demonstration af det, der faktisk er bygget. Saml feedback hos én beslutningstager. Nye ønsker skal beskrives og godkendes, før de bliver ekstra arbejde, og ændrede forudsætninger skal føre til en opdateret plan.

Ved slutlevering gennemgår I acceptkriterierne i det aftalte miljø. Kontrollér den centrale brugerrejse på de aftalte enheder, fejltilstande, formularmodtagelse og adgang til administration. Tilgængelighed skal kontrolleres på det aftalte niveau. W3Cs enkle tilgængelighedstjek er et sted at begynde, men erstatter ikke en fuld vurdering.

Afleveringen bør dokumentere følgende.

1. Hvilken version der er godkendt, og hvilke kendte mangler der eventuelt resterer
2. Kode og relevante design- eller indholdsfiler efter aftalen
3. Virksomhedens adgang til domæne, hosting, CMS og nødvendige tjenester
4. Vejledning til opsætning, opdateringer, backup og gendannelse, hvor relevant
5. Licenser, fornyelser og løbende udgifter med en ansvarlig for hver
6. Periode og vilkår for fejlrettelser samt kontaktvej ved driftsproblemer

For kode på GitHub findes en konkret procedure til at overføre et repository. Den tekniske flytning erstatter ikke aftalen om rettigheder og overfører ikke i sig selv alle eksterne driftskonti.

Afslut med en skriftlig godkendelse eller mangelliste og en aftalt plan for de resterende punkter. Fjern unødvendige leverandøradgange, og kontrollér, at virksomheden kan logge ind og finde dokumentationen. Behold kun den adgang, som en fortsat drifts- eller supportaftale kræver.