Den reelle pris ved at hyre en udvikler er den måned, du venter på at se noget

Du hyrer nogen. Du betaler et depositum. Så sker der i ugevis intet, du faktisk kan holde i hånden.

Der er opkald. Et konceptdokument. Et Figma-link. Et board, der langsomt fyldes med tickets. Det, du ikke har, er en app, du kan åbne på din egen telefon. Den kløft, mellem den dag du betaler, og den dag du første gang ser noget rigtigt køre, er der, hvor det meste af stresset i et softwareprojekt bor. Det er også den del, ingen advarer dig om.

Uger er det optimistiske tal

Jeg overdriver ikke ventetiden. Tallene bakker det op. En udvikler, der kommer ind i et projekt, bruger typisk tre til seks måneder på at nå fuld produktivitet, og seks til tolv måneder eller mere på en kompleks app. Det er optrapningen, før det output, du betaler for, ankommer for fuld kraft. Selv en skarp freelancer, der kommer hurtigt i gang, lægger sjældent fungerende software i dine hænder i de første par uger.

Branchens eget bedste råd er enig. Det første princip i Agile-manifestet er tidlig og kontinuerlig levering af fungerende software, og selv det princip formulerer hyppighed som inden for nogle få uger til nogle få måneder, med en præference for den kortere tidsramme. Så guldstandarden, det som ethvert moderne team stræber efter, måles stadig i uger i bedste fald.

Hvorfor tager det så lang tid? Konceptarbejde. Opsætning af miljøet. Specifikationsdokumenter. Og så den del, der stille æder kalenderen: at vente på dig for feedback, godkendelser, assets og adgange, hvilket konsekvent er den største årsag til forsinkelser i freelanceprojekter. Læg dertil overleveringerne mellem en account manager, en projektleder og den person, der faktisk skriver koden, og hver af dem lægger timers forsinkelse til, før nogen sender en eneste linje.

Ventetiden er ikke kun langsom, den er risikabel

En lang kløft, før du ser fungerende software, er ikke kun irriterende. Den er dyr på en måde, der ikke dukker op på fakturaen.

Du kan ikke korrigere kursen på noget, du ikke kan se. Mens du venter, hober små uoverensstemmelser sig stille op. Alle har travlt, alle antager, at planen er rigtig, og antagelserne størkner. Når en build endelig lander, betyder det at skifte retning, at man skal pille uger af arbejde fra hinanden, så det sker sjældent. Rådet fra de folk, der styrer disse projekter, er kontant: tillad ikke uger eller måneder af udvikling uden synlige resultater. Insister på små skridt, du kan se.

Jeg er enig i det råd. Jeg går bare længere end de fleste.

Hvad jeg gør i stedet: en fungerende app på din enhed i aften

Jeg kører arbejdet som en enkelt dag. Vi taler om morgenen, jeg bygger i løbet af dagen, og ved slutningen har du en native app installeret på din egen telefon, plus kildekoden. Ikke en mockup. Ikke en klikbar prototype fanget i en browserfane. En rigtig Swift- eller Kotlin-app, der kører på rigtig hardware, og som er din.

Det er muligt på grund af tre ting. Sytten års skrivning af native mobilkode, så jeg lærer ikke platformen på din tid. AI i loopet, som fjerner en stor del af det langsomme mekaniske arbejde. Og en direkte linje, uden et bureaulag mellem dig og udvikleren, så morgenens samtale bliver til eftermiddagens kode uden et stafetløb af e-mails.

Hvorfor det ændrer den beslutning, du træffer

Når du hyrer på den sædvanlige måde, binder du penge og uger på baggrund af et løfte og et slide. Du finder ud af, om det var en god idé, en måned senere.

Når den første dag slutter med en app i hånden, beslutter du, hvad der sker derefter, med den faktiske ting foran dig. Hvis den er rigtig, fortsætter vi, og du har allerede et fungerende fundament. Hvis ikke, har du brugt en dag, ikke en måned og et depositum. Din risiko er begrænset til en enkelt arbejdsdag, hvilket er omtrent så lavt, som software bliver.

Det er hele pointen. Den måned, du normalt bruger på at vente, er den mest ubehagelige del af at hyre en udvikler, og det er den del, jeg fjerner.