Af Nicklas K. Frank · Opdateret 10. september 2026 · 5 min. læsning
Bed en Laravel-udvikler om en sammenlignelig opgave, et forslag til den første gennemgang og en forklaring på estimatet. Aftal også, hvor koden ligger, og hvordan en anden udvikler kan overtage.
Start med den opgave, I skal have løst. En udvikler med stærk erfaring i nyudvikling er ikke automatisk den rette til at overtage legacy-kode, diagnosticere performance eller bygge en kritisk integration.
Tjeklisten: det skal du kunne få et konkret svar på
Tjekliste til vurdering af en Laravel-udvikler
Kriterium
Spørg efter
Det skal fremgå
Relevant erfaring
En case med samme type risiko eller opgave
Rolle, kontekst, eget bidrag og dokumenterbart resultat
Første analyse
Hvad undersøges før ændringer?
Kode, versioner, tests, drift, data og kritiske integrationer
Kvalitet
Acceptkriterier og teststrategi
Hvordan de vigtigste flows verificeres før release
Sikker release
Deploy-, backup- og rollback-proces
Hvem gør hvad, og hvordan fejl opdages og håndteres
Estimat
Scope, antagelser, usikkerheder og ændringsproces
Hvad prisen bygger på, og hvad der kan flytte den
Ejerskab
Placering af kode, domæne, hosting og konti
At virksomheden kan fortsætte med en anden leverandør
Samarbejde
Kontaktperson, statusform og tilgængelig kapacitet
Hvem du arbejder med, og hvordan beslutninger træffes
1. Match erfaringen med den konkrete opgave
“Mange års erfaring” er kun nyttigt, hvis erfaringen er relevant. Bed udvikleren forklare en sammenlignelig opgave: Hvad var udgangspunktet? Hvilken rolle havde personen? Hvad blev faktisk leveret? Hvad kunne verificeres bagefter?
Skeln også mellem en kunde, en arbejdsgiver og et projekt, udvikleren blot har været i nærheden af. Mine egne Laravel-cases angiver rolle og periode: migreringsarbejde hos Bonnier Publications, performancearbejde hos Aller Media, bankintegrationer hos Mybanker og produktteams og platformsmigrering hos Hobbii. Det er erfaring fra tidligere ansættelser, ikke kundeudtalelser om mit nuværende konsulentarbejde.
2. Afgræns den første opgave
På en eksisterende kodebase bør første leverance være afgrænset: en gennemgang af kode, afhængigheder, testdækning, infrastruktur og dokumentation. Resultatet skal være en prioriteret risikoliste, anbefalet rækkefølge og et estimat med synlige antagelser.
Bed udvikleren forklare, hvad den næste leverance indeholder, og hvilke beslutninger I skal tage. I bør kunne følge både det færdige arbejde og det brugte budget uden at læse kode.
Spørg, hvordan nye ønsker håndteres. Ved timearbejde bør prioritering og forbrug være synligt. Ved fast pris bør acceptkriterier og ændringer i scope være aftalt. Ved løbende kapacitet bør I vide, hvordan backlog og månedligt timeforbrug styres.
4. Sørg for at virksomheden ejer løsningen
Koden bør ligge i virksomhedens repository, og virksomheden bør eje domæne, hosting og konti til tredjepartstjenester. Adgange skal kunne udskiftes, og deployment må ikke afhænge af én ukendt computer eller personlig konto.
Bed om den dokumentation, en anden erfaren udvikler skal bruge for at installere, forstå og deploye projektet. Det fjerner ikke al personafhængighed, men gør et fremtidigt leverandørskifte håndterbart.
5. Sammenlign samlet pris, scope og risiko
Min offentlige pris er 900 kr./time ekskl. moms eller 600 kr./time ved et løbende samarbejde med fast timeforpligtelse. Et estimat angiver de antagelser, der kan ændre timeforbruget.
Når du sammenligner tilbud, så få de samme poster med: Er moms med eller uden? Er analyse, møder, projektledelse, test, deployment og dokumentation inkluderet? Er det den person, du møder, der udfører arbejdet? Se konkrete prismodeller og budgeteksempler i min guide til Laravel-udvikler pris i 2026.
Syv spørgsmål til den første samtale
1
Hvilken lignende opgave har du selv haft ansvar for?
Bed om rolle, kontekst og resultat — ikke kun kundenavn eller teknologistak.
2
Hvad vil du undersøge, før du estimerer?
Svaret viser, om estimatet bygger på jeres system eller på en standardskabelon.
3
Hvad er den største usikkerhed lige nu?
Bed om at få usikkerheden beskrevet og aftal, hvordan den undersøges.
4
Hvordan tester og releaser du ændringer?
Få den konkrete proces for jeres kritiske flows, staging, backup og rollback.
5
Hvordan følger vi scope, tid og forbrug?
Aftal rytme, beslutningspunkter og hvad der sker, før et estimat overskrides.
Et præcist pris- eller tidsløfte gives, før ukendt kode, integrationer eller data er undersøgt.
Det er uklart, hvem der udfører arbejdet, og hvilken senioritet tilbuddet bygger på.
Leverandøren vil eje repository, domæne eller centrale konti uden en klar forretningsgrund.
Tests, deployment, dokumentation og overdragelse omtales som noget, der kan tænkes på til sidst.
Kandidaten kan ikke forklare, hvornår opgaven kræver en anden specialist eller et større team.
Skal jeg vurdere jeres Laravel-opgave?
Send en kort beskrivelse af målet, systemets Laravel- og PHP-version, de vigtigste integrationer og den ønskede tidsplan. Jeg svarer, om opgaven matcher min erfaring, og hvad det mest fornuftige første skridt er.
