Hvilken udvikler har jeg brug for? Beslutningsguide efter projekttype

Hvilken udvikler du har brug for, afgøres af tre ting: hvad du skal have bygget, hvor stort dit budget er og hvornår det skal være klar. For de fleste små og mellemstore virksomheder lander svaret på en af fire: en WordPress- eller Shopify-udvikler til hjemmesider og webshops, en no-code-udvikler til at teste en idé billigt, en fullstack-udvikler til webapps og systemer, eller et team når meget skal bygges på kort tid.

Jeg er selv freelance fullstack-udvikler, så læs med det forbehold. Guiden er bygget så den også peger væk fra mig når det er det rigtige svar.

Den korte version: hvilken udvikler til hvilket projekt

Find den række der ligner dit projekt bedst. Kolonnen "Typisk svar" er udgangspunktet, og de to sidste kolonner viser hvornår du skal vælge noget andet.

Tabellen er en tommelfingerregel. Resten af guiden går de fire trin igennem så du kan teste dit eget projekt mod den. Vil du først vide hvad de forskellige roller laver, så start med overblikket over typer af udviklere og deres opgaver.

Trin 1: Hvad skal du have bygget?

Start med opgaven, ikke med titlen på udviklerens profil. Den hurtigste vej er at finde det sværeste i projektet, for det er næsten altid det der afgør hvilken type udvikler du skal bruge.

Groft sagt falder projekter i fem grupper:

1. Indhold og salg: hjemmesider, kampagnesider og webshops. Det svære er indhold, design og at få besøgende til at handle, ikke teknikken. En WordPress- eller Shopify-udvikler løser det oftest hurtigere og billigere end en der koder fra bunden. Grænserne står i guiden til hvornår en WordPress-udvikler er det rigtige valg.
2. Arbejdsgange og data: kundeportaler, bookingsystemer, interne værktøjer og integrationer. Det svære er regler, rettigheder og data der skal hænge sammen på tværs af systemer. Her er en fullstack- eller backend-udvikler det typiske svar.
3. Produkter: en MVP (den mindste version du kan sætte foran rigtige brugere) eller en SaaS du vil sælge. Det svære er at bygge lidt nok til at teste og samtidig kunne bygge videre bagefter. Vælg en udvikler der har prøvet at bygge et produkt, ikke kun løst opgaver.
4. Mobil: apps der skal ligge i App Store og Google Play og bruge kamera, GPS eller push-beskeder. Det kræver en appudvikler. Mange har dog nok i en webapp der virker godt på telefonen.
5. Eksisterende kode: skal nogen overtage eller videreudvikle et system, er teknologien allerede valgt. Find en der kender netop den teknologi så du ikke betaler for at de lærer den.

Passer dit projekt i flere grupper, så vælg ud fra den del der er sværest eller dyrest at lave forkert. En webshop med kundespecifikke priser og integration til dit økonomisystem er i praksis et system med en butik ovenpå.

Trin 2: Hvor stort er dit budget?

Budgettet ændrer sjældent hvilken type udvikler du skal bruge. Det ændrer hvor meget der kan bygges og om du overhovedet skal have noget bygget fra bunden endnu. En typisk fejl er at løse et lille budget med en billigere udvikler i stedet for en mindre opgave.

Tallene er et groft skøn over markedsniveauet med en erfaren udvikler og kan ikke erstatte et tilbud. LønRadars oversigt over freelance-timepriser i dansk IT angiver 800-1.200 kr. i timen ekskl. moms for en senior konsulent med 7-12 års erfaring, så 100.000 kr. svarer groft til 80-125 timers arbejde. Prisniveauet for de enkelte projekttyper finder du i prisguiden til softwareudvikling i kroner.

Ligger dit budget under det projektet kræver, har du tre ærlige muligheder: gør første version mindre, start med no-code eller et standardsystem, eller vent til du har pengene. En no-code-prototype kan vise om idéen holder før du bruger penge på kode. Hvor langt den vej rækker, har jeg beskrevet i guiden om hvor grænsen går for no-code.

Husk også at lanceringen ikke er den sidste regning. Software skal opdateres, overvåges og rettes, så sæt penge af til drift hvert år.

Trin 3: Hvornår skal det være klar?

Tidshorisonten afgør hvor mange hænder du skal bruge, ikke hvilken slags. Én udvikler kan bygge meget, men kun i ét tempo.

Har du ikke en fast deadline, er én udvikler ofte både det billigste og det hurtigste valg målt på den samlede tid. Der er ingen overdragelser mellem frontend og backend, ingen statusmøder for at holde fem personer opdateret, og du taler direkte med den der skriver koden. Hvor grænsen går, har jeg skrevet om i hvornår én fullstack-udvikler er nok.

Har du en dato der ikke kan flyttes, fx en messe, en sæsonstart eller et lovkrav, så regn baglæns. Min tommelfingerregel: tag det realistiske timetal fra et estimat og del med cirka 120 timer om måneden (det én person realistisk når på fuld tid). Lander resultatet efter din deadline, har du to muligheder: flere folk på opgaven eller en mindre første version. Spørg også hvor mange timer om ugen udvikleren reelt kan afsætte til dig, for mange freelancere har flere kunder ad gangen.

Flere udviklere gør ikke et projekt lineært hurtigere. Hver ny person giver mere koordinering, så to udviklere når sjældent dobbelt så meget som én. Er tiden meget kort, fx få uger, er en standardplatform eller no-code ofte det eneste realistiske svar.

Trin 4: Hvem skal passe løsningen bagefter?

Det sidste trin handler om samarbejdsformen: freelancer, bureau eller fastansat. Det afgøres mest af hvad der sker efter lanceringen.

En hjemmeside der sjældent ændres, kan en freelancer eller et lille bureau bygge, med en aftale om opdateringer bagefter. Et system der bliver forretningskritisk, kræver at nogen kender koden om et år og har tid til at rette fejl hurtigt. Det kan være en freelancer med en serviceaftale eller et bureau. Hvad der adskiller de to, har jeg sammenlignet i freelancer eller bureau: pris, risiko og kvalitet.

Er produktet hele din forretning, og skal det udvikles hver dag i mange år, er en fastansat udvikler eller et internt team ofte det rigtige på sigt. En erfaren freelancer kan bygge første version og hjælpe dig med at ansætte. Kræver løsningen vagt døgnet rundt, skal du bruge et team fordi én person ikke kan love det.

Uanset hvad du vælger, så sørg for at koden ligger i dit eget repository (kodearkiv) og at adgange til hosting og domæne står i dit navn. Det gør det muligt at skifte udvikler hvis samarbejdet ikke fungerer. Hos mig ejer du koden fra første dag.

Tre eksempler: sådan ender beslutningstræet

Her er tre typiske situationer, og hvor guiden ender. Eksemplerne er konstruerede og bygger ikke på kundecases.

En håndværksvirksomhed der vil have flere henvendelser

Projekttype: indhold og salg, i form af en hjemmeside. Budget: omkring 40.000 kr. Deadline: før højsæsonen om tre måneder. Svaret er en WordPress-udvikler eller en hjemmesidebygger med et godt tema. Med en fullstack-udvikler som mig betaler du for kompetencer opgaven ikke kræver.

En grossist der vil have en portal til sine erhvervskunder

Projekttype: arbejdsgange og data, med kundespecifikke priser og integration til økonomisystemet. Budget: omkring 250.000 kr. Deadline: fleksibel, gerne i drift inden for et halvt år. Svaret er en fullstack-udvikler, med et forprojekt først der afklarer integrationen. En webshopplatform med plugins er fristende, men den er ikke bygget til den slags prisregler, så du ender med at arbejde imod den.

En iværksætter med en SaaS-idé og 75.000 kr.

Projekttype: produkt. Budget: under hvad en kodet MVP typisk koster. Deadline: vil gerne teste inden for to måneder. Svaret er en no-code-prototype der tester om nogen vil betale. Kode giver først mening når der er betalende kunder. Alternativet er en meget smal kodet MVP med ét kerneforløb og intet andet.

Når svaret er: ingen udvikler endnu

Nogle gange er det ærlige svar at du ikke skal hyre nogen endnu. Det gælder typisk i fire situationer:

• Der findes et standardsystem til booking, CRM eller fakturering der dækker det meste af behovet. Et abonnement og en lille tilpasning af din arbejdsgang er næsten altid billigere.
• Du kan ikke beskrive hvem der skal bruge løsningen og hvad de skal kunne gøre i den. Skriv det ned først, ellers betaler du en udvikler for at gætte.
• Problemet er en proces, ikke et system. Software gør en uklar arbejdsgang hurtigere, ikke bedre.
• Du har penge til at bygge, men ikke til at drive løsningen bagefter.

Næste skridt: fra beslutning til første samtale

Når du har været de fire trin igennem, ved du hvilken type udvikler du skal kontakte. Sådan kommer du videre:

1. Skriv en halv side om projektet: hvem skal bruge det, hvad skal det kunne, og hvilke systemer skal det tale med.
2. Notér et budgetniveau og en deadline, også selv om de er usikre.
3. Brug tabellen øverst til at finde den type udvikler du skal kontakte.
4. Tal med to eller tre udviklere af den type, og spørg til projekter der ligner dit og stadig er i drift.
5. Ved større projekter: start med et betalt forprojekt til fast pris så omfang og pris er afklaret før der bygges.

Peger guiden på en fullstack-udvikler til en webapp, en kundeportal eller en SaaS, kan du se hvordan jeg prissætter projekter. Peger den på en anden type udvikler end mig, er det også et brugbart svar.

Ofte stillede spørgsmål

Skal jeg vælge teknologi før jeg vælger udvikler?+

Nej, i de fleste tilfælde ikke. Beskriv opgaven, og lad udvikleren foreslå en teknologi og forklare hvorfor den passer. Undtagelserne er når du allerede har et system i en bestemt teknologi eller når dit eget team skal overtage koden bagefter. Så skal udvikleren kende netop den teknologi godt.

Hvordan ved jeg om en udvikler er erfaren nok til mit projekt?+

Spørg til projekter der ligner dit og stadig kører efter lanceringen. Bed udvikleren forklare hvordan de vil gribe din opgave an og hvad de ser som den største risiko. En erfaren udvikler stiller flere spørgsmål til din forretning end til teknikken og kan forklare valgene uden fagsprog. Tal også gerne med en tidligere kunde.

Kan én udvikler bygge både hjemmeside, webapp og app?+

Hjemmeside og webapp, ja: det er typisk arbejde for en fullstack-udvikler. En app til App Store og Google Play kræver oftest en appudvikler selv om nogle webudviklere også bygger cross-platform-apps. Spørg konkret om udvikleren har udgivet apps før, og overvej om en webapp der virker godt på mobilen kan løse opgaven først.

Hvad gør jeg hvis jeg har valgt den forkerte type udvikler?+

Stop op tidligt i stedet for at bygge videre i håb om at det løser sig. Sørg for at du har adgang til koden og alle konti, og få en anden udvikler til at gennemgå hvad der er lavet. Ofte kan en del genbruges. Det dyreste er at fortsætte i flere måneder med en løsning der ikke passer til opgaven.