Sådan vælger du en webudvikler til din startup

Den rigtige webudvikler til en startup er ikke nødvendigvis den med den længste teknologiliste eller den flotteste portfolio. Det vigtigste er, om udvikleren kan hjælpe dig med at få den rigtige første version i drift uden at bygge unødig kompleksitet eller gøre startupen afhængig af én leverandør.

Når du vælger webudvikler til en startup, bør du især vurdere syv ting: scope, teknisk fit, kodeejerskab, kommunikation, leveringshastighed, drift og risiko. De hænger sammen. En udvikler kan være teknisk stærk og stadig være et dårligt valg, hvis vedkommende ikke kan afgrænse en MVP, dokumentere beslutninger eller gøre løsningen overdragelig.

Start med det problem der skal valideres

En startup har ofte flere idéer end den første version bør indeholde. Derfor er det første valgkriterium ikke framework eller designstil. Det er udviklerens evne til at skelne mellem det, der skal være med nu, og det der kan vente.

Beskriv først:

• hvem den første brugergruppe er
• hvilket problem løsningen skal løse
• hvilken handling brugeren skal kunne gennemføre
• hvilke funktioner der er nødvendige for at teste idéen
• hvilke antagelser I forsøger at validere
• hvad der eksplicit ikke skal med i første version
• om der findes en fast deadline eller budgetramme

Hvis projektet i praksis er et digitalt produkt med login, data, workflows eller anden applikationslogik, er det nyttigt først at afklare forskellen mellem en webapp og en hjemmeside. Det ændrer både kompetencebehov, pris og driftsansvar.

En god kandidat bør kunne udfordre scope uden automatisk at gøre projektet større. Hvis en funktion kan erstattes af en manuel proces, en eksisterende tjeneste eller et enklere flow i første release, bør det i det mindste blive diskuteret.

Vurder teknisk fit ud fra produktet

Teknisk fit betyder ikke, at udvikleren skal bruge en bestemt stack, fordi den er moderne. Det betyder, at erfaringen passer til det produkt, I faktisk skal bygge.

Et simpelt marketingwebsite kræver noget andet end en SaaS-løsning med brugerroller, betaling og database. En markedsplads kræver andre overvejelser end en landingsside, og en prototype har andre krav end et system, der allerede har betalende brugere.

Spørg kandidaten om et eller to projekter med tilsvarende teknisk kompleksitet. Bed om konkrete svar på:

1. Hvilke dele byggede du selv?
2. Hvorfor valgte du den tekniske løsning?
3. Hvad var den største tekniske risiko?
4. Hvordan blev løsningen deployet og overvåget?
5. Hvordan kunne en anden udvikler overtage projektet?

Det sidste spørgsmål er vigtigt. En startup ændrer sig hurtigt. Den person, der bygger version 1, er ikke nødvendigvis den person eller det team, der bygger version 10.

Vær også skeptisk over for overengineering. Microservices, mange cloudtjenester eller en avanceret eventarkitektur kan være rigtige valg senere, men de er ikke kvalitetsstempler i sig selv. Den bedste første arkitektur er ofte den enkleste løsning, der opfylder de reelle krav og stadig kan videreudvikles.

Få kodeejerskab og adgang afklaret før første commit

En startup bør vide præcis, hvad den ejer, og hvilke konti den kontrollerer.

Få skriftligt afklaret:

• hvem der ejer den projektspecifikke kildekode
• hvor repository ligger
• hvem der har administratoradgang
• hvem der ejer domænet
• hvem der kontrollerer hosting og deployment
• hvem der ejer database- og cloudkonti
• hvilke tredjepartslicenser der bruges
• hvad der sker med adgange, hvis samarbejdet stopper
• hvilken dokumentation og hvilke filer der afleveres

Det er ikke nødvendigvis et problem, at udvikleren administrerer infrastrukturen. Problemet opstår, hvis startupen kun kan fortsætte ved at beholde den samme leverandør.

Aftalen bør også skelne mellem projektspecifik kode og generelle komponenter eller værktøjer, som udvikleren allerede ejede. Målet er ikke at kræve ejerskab over alt, men at undgå tvivl om, hvad startupen kan tage med videre.

Brug kommunikationen som en del af den tekniske vurdering

I en startup ændres prioriteringer ofte, fordi ny information kommer til. Derfor er kommunikation ikke et blødt supplement til udviklingen. Det er en del af risikostyringen.

En god udvikler bør kunne forklare:

• hvad der arbejdes på nu
• hvad der blokerer
• hvilke beslutninger du skal træffe
• hvad en ændring betyder for scope og tidsplan
• hvilke tekniske risici der er opdaget
• hvad der er færdigt nok til at blive testet

Du behøver ikke nødvendigvis daglige møder. Et kort skriftligt statusformat kan være bedre, hvis det gør fremdrift, beslutninger og blokeringer synlige.

Vær mere forsigtig, hvis du kun får brede svar som "det er næsten færdigt", eller hvis væsentlige tekniske valg bliver præsenteret som noget, du ikke behøver forstå. Du skal ikke kunne skrive koden, men du bør kunne forstå konsekvensen af beslutningen.

Hastighed handler om feedback, ikke kun om en lanceringsdato

Startups har ofte brug for at komme hurtigt frem. Det gør leveringstid vigtig, men "hurtigst muligt" er et dårligt krav.

Spørg i stedet, hvor hurtigt I kan få noget testbart. En udvikler, der kan levere et lille sammenhængende flow tidligt, giver jer mulighed for at opdage forkerte antagelser, før hele løsningen er bygget.

En praktisk første leverance kan for eksempel være:

• en klikbar eller fungerende kerneflow
• login og én central brugerhandling
• en afgrænset landingsside med den vigtigste konvertering
• en intern version med rigtige data, men uden alle edge cases
• en staging-version som founders kan teste løbende

Høj udviklingshastighed er kun værdifuld, hvis løsningen stadig kan testes, deployes og ændres. Hurtig kode, der kræver en omskrivning efter første kundefeedback, kan være den langsomme løsning samlet set.

Spørg til drift før du vælger udvikler

En løsning er ikke færdig, bare fordi den virker på udviklerens computer.

Afklar hvem der håndterer:

• deployment
• domæne og DNS
• database og backups
• secrets og adgangsstyring
• fejlmonitorering og logs
• sikkerhedsopdateringer
• tredjepartsservices
• fejl efter lancering
• almindelig vedligeholdelse
• videreudvikling

Det betyder ikke, at alt skal købes som en stor driftsaftale fra dag ét. Men ansvaret skal være placeret.

Spørg også, hvad der sker, hvis udvikleren ikke er tilgængelig. Kan en anden kompetent udvikler finde repository, miljøvariabler, deploymentproces og de vigtigste arkitekturbeslutninger? Hvis svaret kræver personlig viden, som kun findes hos én person, har startupen en reel kontinuitetsrisiko.

Se på risikoen i hele leverancen

Når du sammenligner kandidater, så spørg ikke kun "kan de bygge det?". Spørg også "hvad kan gå galt, hvis vi vælger dem?".

Typiske risici er:

• uklart scope, som giver gentagne ekstraregninger
• teknisk løsning, som er unødigt dyr at drive
• kode eller konti, som startupen ikke kontrollerer
• manglende test af centrale brugerflows
• afhængighed af én person uden dokumentation
• en deadline, der kun kan holdes ved at skjule kvalitetsproblemer
• en billig prototype, som fejlagtigt behandles som produktionsklar
• manglende plan for sikkerhed, backup eller fejl efter lancering

Risiko kan ikke fjernes helt. Målet er at gøre den synlig og beslutte bevidst, hvilke kompromiser der er acceptable i den aktuelle fase.

Hvad koster startup-webudvikling?

Der findes ikke én meningsfuld standardpris på startup-webudvikling. En landingsside, en afgrænset MVP og en SaaS-platform er fundamentalt forskellige leverancer.

Pris bør derfor komme efter en første afgrænsning af brugere, kerneflow, data, integrationer og krav til drift. Sammenlign heller ikke kun timepriser. En højere timepris kan være billigere samlet, hvis scope bliver mindre og færre ting skal bygges om.

Hvis du vil forstå prismodeller og tilbud mere detaljeret, så brug guiden om fast pris vs. timepris på webprojekter. For et bredere overblik over, hvad der driver websitepriser, se hvad en hjemmeside til en lille virksomhed koster.

10 spørgsmål du kan stille en webudvikler

Brug de samme spørgsmål til alle kandidater, så svarene bliver sammenlignelige.

1. Hvad mener du er den mindste fornuftige første version af vores produkt?
2. Hvilke dele af vores ønskeliste ville du udskyde, og hvorfor?
3. Har du bygget noget med tilsvarende teknisk kompleksitet?
4. Hvilke tekniske risici ser du allerede nu?
5. Hvem ejer kode, repository, domæne, hosting og data?
6. Hvordan får vi en testbar version tidligt i forløbet?
7. Hvordan håndterer du ændringer i scope?
8. Hvordan bliver løsningen deployet, overvåget og fejlrettet?
9. Hvad skal en anden udvikler bruge for at overtage projektet?
10. Hvad er ikke inkluderet i dit tilbud?

Svarene bør være konkrete nok til, at du kan se forskel på kandidaterne. Hvis alle svar lyder som generelle salgspunkter, mangler du stadig information.

En enkel beslutningsmodel

Når du skal vælge webudvikler til din startup, kan du gennemgå kandidaterne i denne rækkefølge:

1. Scope: Forstår kandidaten, hvad der skal valideres nu, og hvad der kan vente?
2. Teknisk fit: Matcher erfaringen den faktiske kompleksitet?
3. Ejerskab: Har startupen kontrol over kode, data og centrale konti?
4. Kommunikation: Bliver beslutninger, blokeringer og konsekvenser gjort tydelige?
5. Hastighed: Kan I få små, testbare leverancer tidligt?
6. Drift: Er ansvar efter deployment placeret?
7. Risiko: Kan løsningen og samarbejdet fortsætte, hvis planerne ændrer sig?

Hvis du stadig overvejer, om du skal vælge én selvstændig udvikler eller et større team, gennemgår guiden freelance webudvikler vs. webbureau forskellen i kapacitet, ansvar og kontinuitet.

Den bedste kandidat er den, der passer til den fase startupen faktisk er i. Tidligt er evnen til at afgrænse, levere og lære ofte vigtigere end at designe en arkitektur til en fremtid, der endnu ikke er valideret.