Spørgsmålene du skal stille før du skriver kontrakt med et app-bureau
Før du skriver kontrakt med et app-bureau, bør du spørge til teamet og processen, til kodekvalitet og test og til ejerskab, drift og videreudvikling efter lanceringen. Lige så vigtigt er hvordan bureauet svarer: Konkrete, direkte svar er et godt tegn. Svævende eller undvigende svar skjuler derimod ofte en svaghed.
Et salgsmøde med et app-bureau handler lige så meget om hvad du spørger om som om hvad de fortæller. De rigtige spørgsmål afslører hurtigt om bureauet er en langsigtet partner eller en risiko. Her er et batteri af spørgsmål sorteret efter tema, med en guide til hvordan du læser svarene. Tag det med til mødet, og lyt mindst lige så meget til hvordan der svares som til hvad.
Team, proces og kodekvalitet
Start med hvordan arbejdet faktisk foregår. Du køber ikke et hyldeprodukt, men en arbejdsmetode, og den er værd at forstå før du binder dig.
- Hvem i teamet kommer til at arbejde på vores app, og hvilke roller har de?
- Er det de samme personer gennem hele projektet, eller bliver de udskiftet?
- Hvordan ser jeres udviklingsproces ud fra idé til lancering?
- Hvor ofte får vi fungerende dele af appen at se undervejs?
- Hvordan sikrer I kodekvaliteten: code review, test, håndtering af teknisk gæld?
- Hvordan testes appen før den udgives, og hvad testes automatisk?
- Hvordan dokumenteres koden så en anden kan overtage den?
Gode svar er konkrete og gerne med eksempler. Et bureau der beskriver sin proces i klart sprog og kan vise hvordan det tester, har efter al sandsynlighed styr på det. Vage svar af typen “vi er meget agile” uden indhold siger derimod ingenting.
Ejerskab, drift og videreudvikling
Det er de spørgsmål der ofte bliver glemt i begejstringen over udviklingen, men som afgør hvad appen er værd for dig på sigt.
- Hvem ejer koden når projektet er færdigt, og er det reguleret skriftligt?
- Står udviklerkontiene hos Apple og Google i vores navn eller i jeres?
- Hvad indgår i drift og vedligeholdelse, og hvad koster det løbende?
- Hvor hurtigt håndteres kritiske fejl efter lanceringen?
- Hvad sker der hvis vi vil skifte leverandør senere?
- Hvordan håndterer I opdateringer når styresystemerne ændrer sig?
- Hvordan ser en model for videreudvikling af nye funktioner ud?
| Spørgsmålet gælder | Hvorfor det er afgørende |
|---|---|
| Ejerskab af kode | Bestemmer din frihed til at skifte leverandør |
| Udviklerkonti | Skal stå i jeres navn for at undgå fastlåsning |
| Drift og vedligeholdelse | Afgør om appen holder over tid |
Her vil du høre at I ejer koden, at kontiene står i jeres navn og at driften og vedligeholdelsen er klart beskrevet. Svæver bureauet omkring ejerskab eller hvad der indgår efter lanceringen, er det værd at blive mistænksom, for det er netop dér fastlåsning opstår.
Sådan tolker du undvigende svar
Et undvigende svar er sjældent tilfældigt. Når et bureau bliver vagt på et konkret spørgsmål, skjuler det ofte en svaghed det ikke vil sætte ord på. Nogle almindelige mønstre:
- “Det løser vi senere.” På spørgsmål om ejerskab eller drift betyder det ofte at det ikke er gennemtænkt. Bed om et svar nu.
- “Det er teknisk kompliceret at forklare.” Et godt bureau kan forklare sin arbejdsmetode forståeligt. Kan de ikke det, så spørg hvem der kan.
- Et bredt smil i stedet for et svar. Charme erstatter ikke indhold. Gentag spørgsmålet, og bed om et konkret eksempel.
Tommelfingerreglen er enkel: Bed altid om et eksempel eller en skriftlig præcisering når et svar virker uldent. Uklarhed før aftalen bliver næsten aldrig klarere bagefter.
Et konkret scenarie
Lad os sige at et bureau giver fine svar om proces og design, men bliver undvigende på spørgsmålet om hvem der ejer koden. Det er et signal, ikke en detalje. Følg op ved at bede om at få det skrevet ind i aftalen. Nægter de, eller bliver svaret ved med at være uldent, så lad det indgå i vurderingen: Et bureau der ikke vil afklare ejerskabet før aftalen, giver dig en dårligere position i hver fremtidig forhandling.
En god måde at gøre spørgsmålene skarpere på er at have et klart billede af kravene i ryggen så svarene kan måles mod noget konkret. Læs mere om vores ydelser hvis du vil se hvordan vi arbejder med proces og overdragelse, eller kontakt os, så gennemgår vi din situation.
Ofte stillede spørgsmål
Hvilke spørgsmål er vigtigst at stille?
Dem der handler om hvad der sker efter lanceringen: hvem der ejer koden, hvordan drift og vedligeholdelse håndteres og hvordan videreudviklingen ser ud. Mange fokuserer på pris og tidsplan for udviklingen, men det er spørgsmålene om drift og vedligeholdelse der afgør om appen bliver et langsigtet aktiv eller en blindgyde. Stil dem tidligt.
Hvordan kan jeg se at et bureau er seriøst?
På hvor konkret det svarer. Et seriøst bureau beskriver sin proces, sin test og sin overdragelse i klart sprog og kan vise eksempler. Det anerkender også risici og afvejninger i stedet for at love at alt er enkelt. Jo mere direkte og specifikke svarene er, jo mindre er risikoen for ubehagelige overraskelser senere.
Hvad skal jeg spørge om når det gælder kodekvalitet?
Spørg hvordan de sikrer kvaliteten: code review, automatiserede test, og hvordan de håndterer fejl og teknisk gæld. Spørg også hvordan koden dokumenteres og struktureres så en anden kan tage over. Svaret afslører om kvalitet er en indbygget del af arbejdsmetoden eller noget der nævnes i forbifarten, men ikke praktiseres.
Hvorfor er spørgsmålet om ejerskab så vigtigt?
Fordi det afgør din frihed. Ejer du koden, kontiene og rettighederne, kan du skifte leverandør eller selv overtage. Gør du ikke det, er du låst fast hos bureauet med en dårligere forhandlingsposition ved fremtidigt arbejde. Udviklerkonti i app-butikkerne bør stå i jeres navn, ikke bureauets. Få det afklaret før aftalen, ikke efter.
Hvordan tolker jeg et undvigende svar?
Som et advarselssignal der er værd at følge op på. Hvis et bureau bliver vagt omkring test, ejerskab eller hvad der indgår i driften og vedligeholdelsen, er det sjældent en tilfældighed. Bed om et konkret eksempel eller en skriftlig præcisering. Holder svaret stadig ikke, så lad det indgå i beslutningen. Uklarhed før aftalen bliver sjældent klarere bagefter.