Tid til at skifte udviklingsbureau? Sådan gør du

Af Weapp · Opdateret

Et skifte af udviklingsbureau sker i tre trin. Sikr først kode, dokumentation, konti og nøgler mens samarbejdet stadig kører. Planlæg derefter en overlapsperiode på nogle uger hvor det gamle og det nye bureau arbejder parallelt for at overføre viden. Analysér til sidst hvorfor samarbejdet slog fejl så det næste leverandørforhold får bedre forudsætninger fra start.

At skifte udviklingsbureau føles ofte som et større skridt end det er. Med de rigtige forberedelser er det et overskueligt projekt på nogle uger. Uden forberedelser kan det blive dyrt, langsomt og risikabelt for produktet. Her er arbejdsgangen der får skiftet til at gå ordentligt.

Hvornår er et skifte berettiget?

Skeln mellem en enkeltstående fejl og et mønster. En forsinket levering sker også hos gode bureauer; gentagne forsinkelser uden varsel er et mønster. Typiske tegn på at det er tid til at skifte:

  • Leverancer bliver systematisk misset, og kommunikationen forstummer når det går trægt.
  • Kvaliteten svigter: De samme bugs vender tilbage, og små ændringer tager urimeligt lang tid.
  • I er afhængige af én enkelt person hos bureauet, og den person er på vej væk.
  • Priserne glider uden at omfanget vokser, eller hver faktura bliver en overraskelse.
  • Bureauet har mistet den kompetence I har brug for, f.eks. inden for AI eller jeres platform.

Tag altid en ærlig samtale først. Hvis svaret er bortforklaringer i stedet for en plan, har du fået dit svar. Vej også omkostningen ved et skifte op mod at reparere forholdet: En samtale er billigere end en overdragelse, men kun hvis den fører til en faktisk forandring.

Sikr aktiverne før du opsiger aftalen

Gør det mens samarbejdet stadig fungerer. Det er sværere bagefter:

  • Kildekoden: egen kopi og ejerskab i repositoriet, ikke kun læseadgang.
  • Cloudkonti og miljøer: konti hos cloududbyderen i jeres navn.
  • Domæner og DNS: klarhed over hvem der formelt ejer dem.
  • App store-konti: Apple- og Google-konti i jeres navn, med jer som ejer.
  • API-nøgler og tredjepartstjenester: betalingstjenester, e-mail, kort, analyse.
  • Dokumentation: arkitektur, driftsrutiner, kendte fejl, igangværende arbejde.
  • Data og backups: hvor de ligger, hvordan de eksporteres og hvem der har adgang til dem.

Læs samtidig aftalen: opsigelsesvarsel, hvad der indgår i en exit og hvad overdragelsen må koste.

Planlæg overlappet mellem bureauerne

Den mest almindelige fejl er at afslutte det gamle forhold før det nye er kommet i gang. Sigt efter fire til seks ugers overlap hvor det nye bureau laver en kodegennemgang, gradvist overtager driftsansvaret og kan stille spørgsmål til det gamle. Book strukturerede overdragelsesmøder: arkitektur, driftsrutiner, kendte bugs og den backlog der aldrig nåede at blive bygget.

Frys samtidig udviklingen. Under selve overdragelsen bør der ikke bygges ny funktionalitet. Hver ændring midt i et skifte øger risikoen og gør ansvarsspørgsmålet uklart hvis noget går i stykker. Informér også internt: Support, sælgere og andre der vil mærke det hvis produktet opfører sig anderledes, skal vide at et skifte er i gang og hvem de skal henvende sig til.

Regn med at betale for afslutningen. Et groft regneeksempel: Det gamle bureaus afviklingsarbejde kan lande på 40–60 timer og det nye bureaus indlæsning på 60–100 timer. Med bureautimepriser på 1.000–1.700 DKK bliver skiftet en engangsomkostning på cirka 100.000–270.000 DKK. Det er surt, men næsten altid billigere end at lade det nye bureau lave arkæologi i en udokumenteret kodebase uden hjælp.

Analysér hvad der gik galt

Et bureauskifte der ikke følges op af selvransagelse, har det med at gentage sig. Gennemgå det gamle forhold ærligt:

  • Var kravene tydelige, eller måtte bureauet gætte hvad I ville have?
  • Var der en velfungerende rytme for statusmøder og beslutninger, eller blev alt styret via mails bagefter?
  • Lå problemet i bureauets kompetencer, bemanding eller prioritering, eller i et budget der aldrig matchede ambitionen?
  • Hvem hos jer ejede egentlig produktet og forholdet?

Svarene afgør hvad I skal gøre anderledes: grundigere referencetjek, tydeligere aftaler med milepæle, hyppigere demoer eller en udpeget produktejer internt.

Næste skridt

Et velplanlagt skifte tager nogle uger og betaler sig i et produkt der igen kan videreudvikles. Vi hos Weapp har overtaget kodebaser i varierende stand og starter altid samme sted: med en kodegennemgang der giver jer et ærligt billede af situationen før I beslutter jer. Står I over for et skifte? Kontakt os, så ser vi på jeres situation.

Ofte stillede spørgsmål

Skal det gamle bureau udlevere kildekoden?

Det afhænger af hvad aftalen siger, og af om I har betalt det I skal. Er rettighederne overgået til jer ifølge aftalen, er bureauet forpligtet til at udlevere koden. Står der intet om det i aftalen, bliver det en forhandling: endnu en grund til at sikre løbende adgang til repositoriet fra projektstart.

Hvor lang tid tager et bureauskifte?

Med en ordnet overdragelse tager et skifte ofte fire til otte uger fra opsigelsen til det nye bureau arbejder selvstændigt. Mangler der dokumentation, eller er det gamle bureau passivt, kan det tage betydeligt længere fordi det nye bureau så må læse sig til alt gennem koden.

Skal jeg fortælle bureauet at jeg overvejer at skifte?

Oftest ja. En ærlig samtale giver bureauet en chance for at rette op på problemerne, og hvis I alligevel går videre, bliver overdragelsen bedre af en professionel tone. Undtagelsen er hvis tilliden er helt opbrugt: Sikr i så fald aktiver og kopier før du tager samtalen.

Kan et nyt bureau overtage en hvilken som helst kodebase?

Teknisk set oftest ja, men omkostningen varierer med kodens tilstand, dokumentationen og teknologivalgene. Et seriøst bureau starter med en kodegennemgang og giver derefter besked om hvad overtagelsen kræver. Vær skeptisk over for den der lover en gnidningsfri overgang uden at have set koden.

Hvad gør jeg hvis bureauet nægter at samarbejde om overdragelsen?

Læn dig op ad aftalen, og stil kravene skriftligt: kode, dokumentation, konti og data. Tillader aftalen det, kan en tilbageholdt slutbetaling være et pressionsmiddel, men optrap ikke unødigt. Kommer I ingen vegne, er en jurist med speciale i IT-kontrakter næste skridt.