Dags att byta utvecklingsbyrå? Gör så här

Att byta utvecklingsbyrå känns ofta som ett större steg än det är. Med rätt förberedelser är det ett hanterbart projekt på några veckor – utan förberedelser kan det bli dyrt, långsamt och riskabelt för produkten. Här är arbetsgången som gör bytet snyggt.

När är ett byte motiverat?

Skilj på en engångsmiss och ett mönster. En försenad leverans händer även bra byråer; upprepade förseningar utan förvarning är ett mönster. Vanliga signaler på att det är dags:

• Leveranser missas systematiskt och kommunikationen tystnar när det är motigt.
• Kvaliteten sviktar: samma buggar återkommer, små ändringar tar orimligt lång tid.
• Ni är beroende av en enda person hos byrån – och den personen är på väg bort.
• Priserna glider utan att omfattningen växer, eller varje faktura blir en överraskning.
• Byrån har tappat kompetensen ni behöver, till exempel inom AI eller er plattform.

Ta alltid ett ärligt samtal först. Om svaret är bortförklaringar i stället för en plan har du fått ditt besked. Väg också bytets kostnad mot att reparera relationen – ett samtal är billigare än en överlämning, men bara om det leder till faktisk förändring.

Säkra tillgångarna innan du säger upp avtalet

Gör detta medan samarbetet fortfarande fungerar – det är svårare efteråt:

• Källkoden: egen kopia och ägarskap i kodförrådet, inte bara läsrättigheter.
• Molnkonton och miljöer: konton hos molnleverantören ska stå i ert namn.
• Domäner och DNS: kontrollera vem som formellt äger dem.
• Appbutikskonton: Apple- och Google-konton ska vara era, med er som ägare.
• API-nycklar och tredjepartstjänster: betaltjänster, e-post, kartor, analys.
• Dokumentation: arkitektur, driftrutiner, kända fel, pågående arbete.
• Data och backuper: var de ligger, hur de exporteras och vem som kommer åt dem.

Läs samtidigt avtalet: uppsägningstid, vad som ingår i en exit och vad överlämningen får kosta.

Planera överlappen mellan byråerna

Den vanligaste missen är att avsluta den gamla relationen innan den nya är igång. Sikta på fyra till sex veckors överlapp där den nya byrån gör en kodgenomgång, tar över driftansvaret stegvis och kan ställa frågor till den gamla. Boka strukturerade överlämningsmöten: arkitektur, driftrutiner, kända buggar och den backlog som aldrig hann byggas.

Frys samtidigt utvecklingen. Under själva överlämningen bör ingen ny funktionalitet byggas – varje förändring mitt i ett byte ökar risken och gör ansvarsfrågan grumlig om något går sönder. Informera också internt: support, säljare och andra som märker om produkten beter sig annorlunda ska veta att ett byte pågår och vart de vänder sig.

Räkna med att betala för avslutet. Ett grovt räkneexempel: den gamla byråns avvecklingsarbete kan landa på 40–60 timmar och den nya byråns inläsning på 60–100 timmar. Med byråtimpriser på 950–1 600 kr blir bytet en engångskostnad på ungefär 100 000–250 000 kr. Det är surt – men nästan alltid billigare än att låta den nya byrån bedriva arkeologi i en odokumenterad kodbas utan hjälp.

Analysera vad som gick fel

Ett byråbyte som inte följs av självrannsakan brukar upprepa sig. Gå igenom den gamla relationen ärligt:

• Var kravbilden tydlig, eller fick byrån gissa vad ni ville ha?
• Fanns en fungerande rytm för avstämningar och beslut, eller styrdes allt via mejl i efterhand?
• Var problemet kompetens, bemanning eller prioritering hos byrån – eller en budget som aldrig matchade ambitionen?
• Vem hos er ägde egentligen produkten och relationen?

Svaren avgör vad ni ska göra annorlunda: noggrannare referenstagning, tydligare avtal med milstolpar, tätare demos eller en utpekad produktägare internt.

Nästa steg

Ett välplanerat byte tar några veckor och betalar sig i en produkt som går att utveckla igen. Vi på Weapp har tagit över kodbaser i varierande skick och börjar alltid i samma ände: en kodgenomgång som ger er en ärlig bild av läget innan ni bestämmer er. Står ni inför ett byte? Hör av dig så tittar vi på er situation.