På tide å bytte utviklingsbyrå? Slik gjør du det

Av Weapp · Oppdatert 2025-01-15

Et bytte av utviklingsbyrå gjøres i tre steg. Sikre først kode, dokumentasjon, kontoer og nøkler mens samarbeidet pågår. Planlegg deretter en overlappingsperiode på noen uker der det gamle og det nye byrået jobber parallelt for å overføre kunnskap. Analyser til slutt hvorfor samarbeidet sviktet slik at neste leverandørforhold får bedre forutsetninger fra start.

Å bytte utviklingsbyrå føles ofte som et større steg enn det er. Med riktige forberedelser er det et håndterbart prosjekt på noen uker. Uten forberedelser kan det bli dyrt, tidkrevende og risikabelt for produktet. Her er fremgangsmåten som gjør byttet ryddig.

Når er et bytte berettiget?

Skill mellom en enkeltstående glipp og et mønster. En forsinket leveranse skjer også hos gode byråer; gjentatte forsinkelser uten forvarsel er et mønster. Vanlige tegn på at det er på tide:

Leveransefrister ryker systematisk, og kommunikasjonen stilner når det går tungt.
Kvaliteten svikter: De samme feilene dukker opp igjen, og små endringer tar urimelig lang tid.
Dere er avhengige av én eneste person hos byrået, og den personen er på vei ut.
Prisene glir uten at omfanget vokser, eller hver faktura blir en overraskelse.
Byrået har mistet kompetansen dere trenger, for eksempel innen AI eller plattformen dere bruker.

Ta alltid en ærlig samtale først. Hvis svaret er bortforklaringer i stedet for en plan, har du fått svaret ditt. Vei også kostnaden ved et bytte mot å reparere forholdet. En samtale er billigere enn en overlevering, men bare hvis den fører til faktisk endring.

Sikre verdiene før du sier opp avtalen

Gjør dette mens samarbeidet fortsatt fungerer. Etterpå er det vanskeligere:

Kildekoden: egen kopi og eierrettigheter i kodelageret (repoet), ikke bare lesetilgang.
Skykontoer og miljøer: kontoene hos skyleverandøren skal stå i deres navn.
Domener og DNS: sjekk hvem som formelt eier dem.
Kontoer i appbutikkene: Apple- og Google-kontoene skal være deres, med dere som eier.
API-nøkler og tredjepartstjenester: betalingstjenester, e-post, kart, analyse.
Dokumentasjon: arkitektur, driftsrutiner, kjente feil, pågående arbeid.
Data og sikkerhetskopier: hvor de ligger, hvordan de eksporteres, og hvem som har tilgang til dem.

Les samtidig avtalen: oppsigelsestid, hva som inngår når avtalen avsluttes, og hva overleveringen kan koste.

Planlegg overlappen mellom byråene

Den vanligste tabben er å avslutte det gamle forholdet før det nye er i gang. Sikt mot fire til seks ukers overlapp der det nye byrået gjør en kodegjennomgang, tar over driftsansvaret gradvis og kan stille spørsmål til det gamle. Sett opp strukturerte overleveringsmøter: arkitektur, driftsrutiner, kjente feil og backloggen det aldri ble tid til å bygge.

Frys samtidig utviklingen. Under selve overleveringen bør det ikke bygges ny funksjonalitet. Hver endring midt i et bytte øker risikoen og gjør ansvarsspørsmålet uklart hvis noe går i stykker. Informer også internt: Kundestøtte, selgere og andre som vil merke om produktet oppfører seg annerledes, skal vite at et bytte pågår, og hvor de skal henvende seg.

Regn med å betale for avslutningen. Et grovt regneeksempel: Det gamle byråets avviklingsarbeid kan lande på 40–60 timer og det nye byråets innlesing på 60–100 timer. Med timepriser hos byråer på 1 200–2 000 kr blir byttet en engangskostnad på omtrent 120 000–310 000 kr. Det er surt, men nesten alltid billigere enn å la det nye byrået drive arkeologi i en udokumentert kodebase uten hjelp.

Analyser hva som gikk galt

Et byråbytte som ikke følges av selvransakelse, har en tendens til å gjenta seg. Gå ærlig gjennom det gamle forholdet:

Var kravene tydelige, eller måtte byrået gjette hva dere ville ha?
Fantes det en fungerende rytme for oppfølgingsmøter og beslutninger, eller ble alt styrt via e-post i etterkant?
Lå problemet i kompetanse, bemanning eller prioritering hos byrået, eller i et budsjett som aldri sto i forhold til ambisjonene?
Hvem hos dere eide egentlig produktet og forholdet til byrået?

Svarene avgjør hva dere skal gjøre annerledes: grundigere referansesjekk, tydeligere avtaler med milepæler, hyppigere demoer eller en utpekt produkteier internt.

Neste steg

Et godt planlagt bytte tar noen uker og betaler seg tilbake i form av et produkt som igjen kan videreutvikles. Vi i Weapp har tatt over kodebaser i varierende forfatning og begynner alltid i samme ende: en kodegjennomgang som gir dere et ærlig bilde av situasjonen før dere bestemmer dere. Står dere foran et bytte? Ta kontakt, så ser vi på situasjonen sammen med dere.

Ofte stilte spørsmål

Må det gamle byrået utlevere kildekoden?

Det avhenger av hva avtalen sier, og om dere har betalt det dere skal. Har rettighetene gått over til dere etter avtalen, er byrået forpliktet til å utlevere koden. Står det ingenting om dette i avtalen, blir det en forhandling. Det er enda en grunn til å sikre løpende tilgang til kodelageret fra prosjektstart.

Hvor lang tid tar et byråbytte?

Med en ordnet overlevering tar et bytte ofte fire til åtte uker fra oppsigelsen til det nye byrået jobber selvstendig. Mangler dokumentasjonen, eller er det gamle byrået passivt, kan det ta betydelig lenger tid fordi det nye byrået da må finne ut av alt ved å lese koden.

Bør jeg si fra til byrået at jeg vurderer å bytte?

Som regel ja. En ærlig samtale gir byrået en sjanse til å rette opp problemene, og hvis dere likevel går videre, blir overleveringen bedre av en profesjonell tone. Unntaket er når tilliten er helt brukt opp. Sikre da verdier og kopier før du tar samtalen.

Kan et nytt byrå ta over hvilken som helst kodebase?

Teknisk sett som regel ja, men kostnaden varierer med kodens tilstand, dokumentasjonen og teknologivalgene. Et seriøst byrå begynner med en kodegjennomgang og sier deretter hva overtakelsen krever. Vær skeptisk til den som lover en sømløs overgang uten å ha sett koden.

Hva gjør jeg hvis byrået nekter å samarbeide om overleveringen?

Støtt deg på avtalen og still kravene skriftlig: kode, dokumentasjon, kontoer og data. Hvis avtalen tillater det, kan det å holde tilbake sluttbetalingen være et pressmiddel, men ikke trapp opp unødig. Kommer dere ingen vei, er en jurist som er spesialisert på IT-kontrakter, neste steg.