Fra første opkald til lancering: sådan foregår et udviklingsforløb med mig som freelancer

Et udviklingsforløb med mig som freelance udvikler følger syv trin: din henvendelse, et første opkald, et betalt forprojekt til fast pris ved større projekter, et tilbud, selve udviklingen, test og lancering og til sidst drift og videreudvikling. Du taler med mig hele vejen, fra den første snak til koden kører, og du ejer koden fra første dag.

Nedenfor kan du se hvad der sker i hvert trin, hvor lang tid det typisk tager, hvad du får ud af det, og hvad jeg har brug for fra dig. Vil du gå mere i dybden med selve udviklingsfaserne, fx design, sprints og accepttest, så læs gennemgangen af softwareudviklingsprocessen fra idé til drift.

Den korte version: forløbet i syv trin

Mindre opgaver, fx en afgrænset integration eller en ny funktion i et eksisterende system, springer typisk forprojektet over og går direkte fra opkald til tilbud. Varighederne er vejledende, for et lille internt værktøj og en kundeportal med betaling og integrationer er to meget forskellige forløb.

Det er vigtigt at prioritere hårdt og få noget i hænderne tidligt. Læs mere om valg og prioriteringer i guiden fra idé til SaaS. Resten af artiklen går trin for trin igennem forløbet.

Trin 1 og 2: henvendelsen og det første opkald

Det hele starter med en kort besked. Kontaktformularen spørger til projekttype, budget og tidsramme, og et par linjer om hvad du vil have bygget er nok. Du behøver ikke en kravspecifikation. Jeg svarer inden for 1 hverdag, enten med et forslag til et opkald eller med et ærligt svar om at opgaven passer bedre til en anden.

Det første opkald er en uforpligtende samtale. Jeg bruger tiden på at forstå forretningen bag projektet, ikke kun listen over funktioner. Typisk spørger jeg til:

• hvilket problem løsningen skal løse, og for hvem
• hvordan opgaven bliver løst i dag, fx i regneark, mails eller et gammelt system
• hvad det vigtigste er at første version kan
• hvem hos dig der træffer beslutningerne, og hvor meget tid de har
• hvad budgettet og tidsrammen er, også selvom de kun er grove

Budgettet er det spørgsmål mange helst springer over. Men et groft interval gør samtalen langt mere brugbar fordi det afgør om løsningen skal bygges fra bunden, om en standardløsning kan klare en del af opgaven, eller om første version skal skæres ned. Du kan se hvordan jeg prissætter opgaver på prissiden.

Efter opkaldet ved du om jeg er det rigtige valg til opgaven. Er jeg ikke det, siger jeg det, og når jeg kan, fortæller jeg hvad du skal kigge efter i stedet.

Trin 3: forprojektet, hvor projektet bliver konkret

Før større projekter laver jeg et betalt forprojekt til fast pris. Det kan virke som en omvej, så her er begrundelsen: Et tilbud på et helt system ud fra ét opkald er et gæt. Enten lægger udvikleren en stor buffer oven i prisen, eller også dukker de skjulte krav op midt i udviklingen, hvor de er dyrest at håndtere. Forprojektet flytter de svære spørgsmål frem til et tidspunkt hvor de er billige at svare på.

Et forprojekt forløber typisk sådan:

1. Jeg gennemgår arbejdsgange, brugere, data og eksisterende systemer sammen med dig og gerne med nogle af dem der skal bruge løsningen.
2. Opgaven bliver afgrænset: hvad skal med i første version, og hvad kan vente til senere.
3. Jeg lægger en teknisk plan for valg af teknologi, hosting, integrationer og hvad der skal ske med eksisterende data.
4. De mest usikre dele af opgaven bliver beskrevet, sammen med hvordan de kan håndteres.
5. Ud fra det hele får du en pris og en tidsplan for selve udviklingen.

Resultatet er et skriftligt grundlag du kan træffe beslutning på. Vælger du ikke at gå videre, har du stadig en afgrænsning og en plan som en anden udvikler kan regne på. Forprojektet giver dig med andre ord en mulighed for at stoppe før de store beløb er brugt.

Er dit projekt en MVP (en første, enkel version af et produkt), har jeg beskrevet hvordan afgrænsningen og de første uger ser ud i min MVP-proces uge for uge.

Trin 4: tilbud, aftale og hvem der ejer hvad

Når forprojektet er færdigt, får du et tilbud på udviklingen. Det beskriver hvad der bliver bygget, hvad der ikke er med, hvordan der bliver faktureret, og hvordan ændringer undervejs bliver håndteret. Det sidste er vigtigt. Der kommer altid nye idéer når folk begynder at bruge noget, og aftalen skal sige hvad der sker med dem så hverken du eller jeg bliver overrasket.

Tre ting skal være på plads før den første linje kode bliver skrevet:

• Ejerskab: Du ejer koden fra første dag. I praksis ligger koden i et repository (kodearkiv) du selv har adgang til. Du er altså aldrig afhængig af at jeg udleverer den.
• Adgange: Domæner, hosting og tredjepartstjenester som betaling og mail bør stå i din virksomheds navn, ikke i udviklerens. Det gør det enkelt at skifte leverandør hvis du en dag får brug for det.
• Persondata: Skal jeg have adgang til persondata, fx dine kunders oplysninger i en database, behandler jeg dem på dine vegne. Som dataansvarlig er det dit ansvar at der ligger en databehandleraftale, som Datatilsynet beskriver i sin vejledning om dataansvarlige og databehandlere.

Det er ikke juridisk rådgivning. Står der meget på spil, så få en advokat til at læse aftalen igennem før du skriver under.

Trin 5 og 6: udvikling, test og lancering

Sådan følger du med undervejs

Udviklingen foregår i korte runder, og hver runde ender med noget du kan se og afprøve. Det betyder at du opdager misforståelser efter dage, ikke efter måneder. Du taler direkte med mig, så et spørgsmål om en knap eller en regel i systemet kan afklares med en kort besked i stedet for et statusmøde. Hvilke værktøjer jeg bruger til kode, test og kommunikation, har jeg samlet i mit værktøjsbælte som freelance udvikler.

Det vigtigste du kan gøre i den fase, er at svare hurtigt og afprøve det jeg viser dig. Et projekt går sjældent i stå på grund af koden. Det går i stå når en beslutning ligger og venter.

Når du får nye ønsker undervejs

Nye ønsker er normale. Jeg vurderer hvert ønske for sig: Passer det ind i det aftalte, eller skal det have sin egen pris? Nogle gange er det rigtige svar at bytte så en ny funktion erstatter noget der var planlagt, og budgettet holder. Andre gange bør ønsket vente til efter lanceringen. Det afgørende er at beslutningen bliver truffet åbent, og at du kender konsekvensen for pris og tid før arbejdet starter.

Test og lancering

Før lanceringen afprøver du løsningen med rigtige arbejdsgange og gerne rigtige data. Jeg tester det tekniske: at formularer, betalinger, mails og integrationer virker, at løsningen er hurtig, og at der er backup. Selve lanceringen bliver planlagt så den sker på et roligt tidspunkt med tid til at rette fejl de første dage.

Erstatter den nye løsning en gammel hjemmeside, skal de gamle adresser også pege det rigtige sted hen så du ikke mister placeringer i Google. Hvordan jeg selv har tænkt SEO og hastighed ind fra start, kan du læse i historien om hvordan jeg byggede simonij.com.

Trin 7: efter lanceringen

En webløsning bliver aldrig helt færdig. Framework og pakker skal opdateres, nogen skal holde øje med fejl og oppetid, og når brugerne kommer i gang, opstår der idéer til forbedringer. Derfor hører det med i tilbuddet hvad der skal ske efter lanceringen. Det er typisk en af to modeller:

• En fast aftale om vedligehold, hvor opdateringer, overvågning og mindre rettelser bliver lavet løbende.
• Hjælp efter behov, hvor du kontakter mig når der skal laves noget nyt.

Den første passer til løsninger din forretning er afhængig af hver dag. Den anden kan være nok til en enkel hjemmeside med få ændringer. Du kan se hvad en fast aftale dækker på siden om vedligehold og videreudvikling.

Mit råd er at tage stilling til det før lanceringen og ikke den dag noget går ned. En løsning uden en plan for opdateringer bliver langsomt dyrere at rette i, og det opdager du først når det haster.

Hvornår et forløb med mig ikke passer

Jeg vil hellere sige nej tidligt end tage en opgave jeg ikke er den rigtige til. Et forløb med mig passer typisk ikke når:

• du skal bruge design, branding, tekster og udvikling på samme tid. Så er et bureau med flere fagligheder ofte et bedre valg.
• du har brug for en udvikler der arbejder på produktet hver dag i mange år. Så er en ansættelse sandsynligvis den rigtige vej på længere sigt.
• den laveste timepris er dit vigtigste kriterium. Så finder du typisk lavere priser på markedspladser og hos offshore-udviklere.
• ingen hos dig har tid til at svare på spørgsmål og afprøve løsningen undervejs.
• du er privatperson. Jeg arbejder for virksomheder.

Det jeg til gengæld har brug for fra dig, er overskueligt: én fast kontaktperson der kan træffe beslutninger, svar inden for et par dage når jeg spørger, og tid til at afprøve det der bliver bygget. Med det på plads er det sjældent selve udviklingen der bliver det svære.

Næste skridt: sådan forbereder du det første opkald

Du får mest ud af det første opkald hvis du har tænkt over nogle af punkterne herunder. Du behøver ikke have svar på det hele. Det er netop det opkaldet og forprojektet er til.

Når du er klar, kan du beskrive dit projekt på kontaktsiden. Så vender jeg tilbage inden for 1 hverdag med et forslag til et opkald eller et ærligt svar om at opgaven passer bedre til en anden.

Ofte stillede spørgsmål

Hvad koster et forprojekt?+

Det afhænger af projektets størrelse, men du får prisen som en fast pris før forprojektet går i gang, så du ved præcis hvad du betaler for. Som tommelfingerregel bør et forprojekt kun udgøre en lille del af den samlede udvikling. Til gengæld får du en langt mere præcis pris på resten og slipper for at betale for en stor buffer i et tilbud lavet på et løst grundlag.

Hvad hvis budgettet ikke rækker til alt det jeg gerne vil have?+

Så bliver første version skåret til så den løser det vigtigste problem, og resten bliver lagt i en senere fase. At finde den grænse er en af de vigtigste opgaver i forprojektet. Ofte er det bedre at lancere en mindre løsning og bygge videre ud fra hvordan den bliver brugt, end at sprede budgettet tyndt over alle ønsker på én gang.

Hvad sker der hvis du bliver syg eller ikke er til rådighed?+

Den risiko skal du kunne håndtere uanset hvilken udvikler du vælger. Derfor ejer du koden fra første dag og har selv adgang til den, og jeg anbefaler at domæner og hosting står i dit navn. Så kan en anden udvikler overtage hvis det bliver nødvendigt. Spørg gerne ind til det på det første opkald så du ved præcis hvordan det er sat op.

Kan du overtage et projekt som en anden udvikler har startet?+

Ja. Forløbet ser lidt anderledes ud fordi det typisk starter med en gennemgang af den eksisterende kode, hosting og dokumentation i stedet for et klassisk forprojekt. Så ved du hvilken stand løsningen er i, hvad der bør rettes først, og om det kan betale sig at bygge videre på det der findes før du beslutter dig.