Przejście z software house na własny zespół: plan, który nie zatrzymuje roadmapy

Przejście z software house na własny zespół zajmuje 3-6 miesięcy i prowadzi się je równolegle do rozwoju produktu, nie zamiast niego. Sekwencja jest zawsze ta sama: najpierw przejmujesz własność (kod, infrastruktura, wiedza), potem zatrudniasz rdzeń zespołu, na końcu wygaszasz kontrakt z software house w roli, która maleje stopniowo, a nie urywa się z dnia na dzień. Przeprowadziłem ten proces w Mindgram, gdzie produkt stawiany przez zewnętrzny software house przeszedł pod własne, cross-functional teams, przy presji inwestorów na tempo. Poniżej plan, którego bym użył ponownie.

Software house to dobry model na walidację i MVP. Przestaje nim być, gdy pojawia się któryś z tych sygnałów: koszt miesięczny software house przekracza koszt 2-3 własnych inżynierów, tempo iteracji ogranicza kolejka u dostawcy, a nie wasze decyzje, produkt staje się rdzeniem przewagi konkurencyjnej (wtedy wiedza o nim musi być w środku), albo zbliża się runda i inwestor zapyta, kto właściwie rozwija technologię, w którą inwestuje.

Ostatni punkt bywa wyzwalaczem: brak wewnętrznych kompetencji tech to jedna z częstszych flag w due diligence, o czym pisałem w przygotowaniu do tech DD.

Faza 1, przejęcie własności (tydzień 1-4): cel to kod, infrastruktura, dostępy i dokumentacja na kontach spółki, adresowane ryzyko to vendor lock-in i utrata IP. Faza 2, rdzeń zespołu (tydzień 3-12): cel to pierwszych 2-4 inżynierów, w tym jeden senior lub lead, adresowane ryzyko to brak komu przekazać wiedzy. Faza 3, transfer wiedzy (tydzień 8-20): cel to wspólna praca zespołu z software house na jednym backlogu, adresowane ryzyko to wiedza zamknięta w głowach dostawcy. Faza 4, wygaszenie (tydzień 16-24): cel to software house schodzący do roli wsparcia, a potem zero, adresowane ryzyko to urwanie ciągłości delivery.

Fazy celowo nachodzą na siebie. Największy błąd tego procesu to sekwencja "najpierw zwolnimy software house, potem zatrudnimy ludzi": między jednym a drugim produkt stoi, a nowy zespół uczy się systemu bez nikogo, kto go zna.

Zanim zatrudnisz kogokolwiek, uporządkuj własność. Repozytoria w organizacji spółki (nie na kontach dostawcy), infrastruktura i domeny na waszych kontach z waszym billingiem, umowa z software house z jasnym przeniesieniem IP na wszystko, co powstało, dostępy zinwentaryzowane, sekrety zrotowane. To tydzień-dwa pracy administracyjnej, a przesądza o tym, czy dalsze fazy prowadzisz z pozycji właściciela, czy petenta. Jeśli umowa nie przenosi IP, negocjuj to teraz, póki relacja jest dobra i kontrakt trwa.

Pierwszy hire to nie "programista do pomocy", tylko przyszły właściciel systemu: senior inżynier lub tech lead, który poprowadzi transfer wiedzy i wyznaczy standardy. Dopiero wokół niego dokładasz 1-3 inżynierów. Pełną sekwencję ról rozpisuję w osobnym tekście o pierwszych zatrudnieniach tech.

Na czas przejścia potrzebny jest też ktoś, kto zaprojektuje docelową architekturę zespołu i oceni, co z kodu dostawcy nadaje się do rozwoju, a co do przepisania. Jeśli nie masz technicznego co-foundera, to typowa rola dla fractional CTO: kilkumiesięczne zaangażowanie dokładnie na okres przejścia.

Dokumentacja przekazana w PDF-ach to nie jest transfer wiedzy. Działa jedno: wspólna praca na jednym backlogu. Wasz zespół bierze zadania w systemie od pierwszego tygodnia, software house robi code review i odpowiada na pytania, stopniowo zamieniacie się rolami (po 4-6 tygodniach to dostawca robi taski, a wasz lead review). Do tego twarde minimum dokumentacyjne: setup środowiska od zera, diagram architektury, runbooki dla incydentów, lista długów i znanych problemów prosto od inżynierów dostawcy, póki są dostępni.

Software house nie znika w dniu podpisania aneksu. Schodzi po schodach: pełne delivery, potem wybrane obszary, potem wsparcie na żądanie (pula godzin miesięcznie na pytania i awarie), potem zero. Pula wsparcia na 2-3 miesiące po przejęciu kosztuje niewiele, a usuwa najgorszy scenariusz: krytyczna awaria w trzecim tygodniu samodzielności i nikt nie zna tej części systemu.

Ile kosztuje przejście na własny zespół? Przejściowo płacisz podwójnie: kontrakt z software house i pensje nowego zespołu przez 2-4 miesiące nakładki. To koszt polisy przed zatrzymaniem produktu. Po przejściu miesięczny koszt zwykle spada albo za te same pieniądze dostajesz wielokrotnie szybsze iteracje, bo znika kolejka i narzut komunikacyjny.

Czy przepisywać kod po software house? Domyślnie nie. Decyzję podejmuj per moduł, na podstawie oceny seniora, który będzie ten kod utrzymywał: co blokuje rozwój, co generuje awarie, a co po prostu jest brzydkie, ale działa. Przepisywanie wszystkiego od zera to klasyczny sposób na zatrzymanie roadmapy na dwa kwartały bez wartości dla klienta.

Co jeśli software house utrudnia przejście? Dlatego faza własności idzie pierwsza, póki współpraca trwa i dostawca ma motywację. Profesjonalne software house'y znają ten cykl i współpracują, bo referencja jest dla nich warta więcej niż przeciąganie kontraktu. Jeśli trafisz na opór przy wydaniu dostępów lub IP, to sygnał, żeby przyspieszyć, nie zwolnić.

Jak długo trwa, zanim własny zespół osiągnie tempo dostawcy? Przy dobrze poprowadzonym transferze zespół osiąga tempo dostawcy w 2-3 miesiące od skompletowania rdzenia, a potem je przekracza, bo znika narzut pośrednika. Bez nakładkowego transferu wiedzy ten sam proces potrafi zająć dwa razy dłużej i kosztować kilka poważnych incydentów.

Jeśli rozważasz przejęcie rozwoju do środka, umów bezpłatny audyt. W 30 minut ocenię twoją sytuację kontraktową, stan kodu z perspektywy przejęcia i zaproponuję sekwencję na twoje warunki. Prowadzę takie przejścia end-to-end w ramach budowania zespołów tech-product.