Przejęcie projektu po innym wykonawcy zaczyna się zwykle od jednego z trzech zdań: "wykonawca przestał odpisywać", "każda zmiana trwa miesiącami" albo "boimy się cokolwiek ruszyć". Robimy takie przejęcia regularnie i ten tekst opisuje, jak wygląda proces od środka: co sprawdzamy, co zabezpieczamy w pierwszej kolejności i kiedy uczciwie mówimy, że taniej będzie napisać od nowa.
Najpierw dostępy, potem oceny
Zanim ktokolwiek oceni kod, policz, co masz w rękach: dostęp do domeny, hostingu, repozytorium, bazy danych, skrzynek pocztowych i kont zewnętrznych usług. To one decydują o Twojej pozycji. System z pełnymi dostępami przejmuje się w tygodnie; system, w którym domena i serwer wiszą na prywatnym koncie byłego wykonawcy, bywa zakładnikiem. Jeśli współpraca jeszcze trwa, choć się psuje, odzyskanie dostępów jest pierwszym ruchem, ważniejszym niż jakakolwiek dyskusja o jakości.
Audyt przejęciowy: co sprawdzamy
Audyt przed przejęciem odpowiada na trzy pytania: czy system da się bezpiecznie utrzymać, ile kosztuje jego rozwój i gdzie leżą miny. Patrzymy na kod, ale też na wszystko dookoła: kopie zapasowe, aktualność zależności, sposób wdrażania zmian, dokumentację. Wynik dostajesz jako raport z rekomendacją i kwotami, nie jako listę technicznych wyzwisk na poprzednika.
| Obszar audytu | Pytanie, na które odpowiada | Czerwona lampka |
|---|---|---|
| Dostępy i własność | Czy kontrolujesz swój system | Domena albo serwer na prywatnym koncie wykonawcy |
| Kopie zapasowe | Co się stanie po awarii | Brak kopii albo kopie nigdy nie testowane |
| Zależności i wersje | Jak daleko od wsparcia bezpieczeństwa | Framework porzucony lata temu, bez aktualizacji |
| Jakość kodu | Ile kosztuje każda zmiana | Brak struktury, kopiuj-wklej, zero testów |
| Dokumentacja i wdrożenia | Czy ktokolwiek nowy wejdzie w projekt | Wdrażanie przez ręczne kopiowanie plików |
Pierwsze 48 godzin po odzyskaniu dostępów
Zanim ruszy jakakolwiek ocena kodu, zabezpieczamy stan posiadania. Pełna kopia zapasowa plików i bazy ląduje w miejscu, do którego poprzedni wykonawca nie ma dostępu. Hasła i klucze do serwera, bazy oraz kont usług zewnętrznych zmieniamy na nowe, a stare sesje wygaszamy. Spisujemy inwentarz kont: co jest podpięte, na kogo, z jaką kartą płatniczą, bo wygasła karta poprzednika potrafi wyłączyć firmową pocztę w środku kwartału. Blokujemy też automatyczne wdrożenia ze starych repozytoriów, żeby nikt przypadkiem albo celowo nie nadpisał działającej wersji. Dopiero na tak zabezpieczonym gruncie zaczyna się audyt.
Rozwijać czy przepisać: jak zapada decyzja
Wbrew stereotypowi programistów nie wszystko trzeba pisać od nowa. Rozwijamy dalej, gdy fundament jest zdrowy: popularny framework, sensowna struktura, aktualne zależności. Przepisujemy, gdy koszt każdej zmiany w starym kodzie przekracza koszt budowy odpowiednika, co przy zapuszczonych projektach następuje szybciej, niż się wydaje. Decyzję podpieramy liczbami z audytu: ile kosztuje ta sama funkcja w starym i nowym kodzie.
Bywa też droga środka: system działa na starym silniku, a nowe moduły powstają obok, w zdrowym kodzie, połączone przez API. Stary rdzeń gaśnie stopniowo, bez wielkiego wybuchu. Mechanikę takiego etapowania opisujemy na stronie o tworzeniu aplikacji webowych.
Przejęcie krok po kroku
- Zabezpieczenie: przepięcie domeny, serwera i kont na Ciebie, natychmiastowa kopia zapasowa całości.
- Audyt: kod, infrastruktura, zależności, dokumentacja. Raport z rekomendacją i kwotami.
- Stabilizacja: łatanie dziur bezpieczeństwa i aktualizacje, zanim ruszy jakikolwiek rozwój.
- Dokumentacja startowa: spisanie, jak system działa i jak się go wdraża, żeby wiedza przestała być ustna.
- Rozwój albo migracja: według decyzji z audytu, etapami z osobnymi odbiorami.
Ile kosztuje trwanie w złym układzie
Decyzję o przejęciu odkłada się miesiącami, bo bieżący układ "jakoś działa". Policz jednak drugą stronę rachunku: zmiany, które nie wchodzą, bo każda wycena u obecnego wykonawcy boli; ryzyko bezpieczeństwa rosnące z każdym miesiącem bez aktualizacji; zależność od jednej osoby, której urlop zatrzymuje firmę. Do tego koszty okazji: konkurencja wdraża, a Ty czekasz na odpowiedź na maila sprzed trzech tygodni. Zdrowe zasady współpracy na przyszłość, od praw do kodu po odbiory etapów, zebraliśmy w artykule o umowie z wykonawcą: przy przejęciu podpisuje się je od nowa, lepiej.
Ile to kosztuje i trwa
Audyt przejęciowy to u nas zwykle 2 000 do 5 000 zł netto, zależnie od skali systemu, i tydzień do dwóch pracy. Stabilizacja po audycie bywa różna: od kilku godzin przy zdrowym projekcie po osobny etap przy zapuszczonym. Dalsze koszty wynikają już z decyzji rozwijać czy przepisać, wycenianej jak każdy projekt: spisem funkcji z wiążącą kwotą, o czym więcej w tekście o kosztach aplikacji webowej.
Czego rzetelny audyt nie obieca
Uczciwość wymaga też granic. Audyt nie daje gwarancji na cudzy kod: mówi, co widać i co z tego wynika, ale miny zakopane głęboko potrafią wybuchnąć dopiero przy zmianach. Nie obiecuje też, że stabilizacja załatwi temat raz na zawsze, bo zapuszczony projekt bywa jak stary dom: naprawa jednej rzeczy odsłania następną. I nie zastąpi decyzji biznesowej: audyt dostarcza liczb do wyboru między rozwojem a przepisaniem, ale wybór, z jego konsekwencjami budżetowymi, należy do Ciebie. Za to wszystko, co w raporcie stoi, odpowiadamy wprost: każdą tezę da się sprawdzić w kodzie albo na serwerze.
Najczęściej zadawane pytania o przejęcie projektu
Czy przejmiecie projekt bez kontaktu z poprzednim wykonawcą?
Tak, o ile masz dostępy albo da się je odzyskać przez rejestratora domeny i dostawcę hostingu. Kontakt z poprzednikiem pomaga, ale nie jest warunkiem: kod i infrastruktura mówią większość prawdy same. Przy odzyskiwaniu dostępów podpowiadamy ścieżki, w tym formalne.
Nie mam dostępu do kodu strony. Czy to koniec?
Nie: jeśli kontrolujesz domenę, najgorszy scenariusz to odbudowa serwisu z treści, które da się pobrać z działającej strony. Bywa, że kod odzyskuje się z serwera przez dostęp hostingowy. Każdą z tych dróg oceniamy w audycie, zanim padnie jakakolwiek kwota. A jeśli kończy się to budową nowego serwisu, checklistę bezpiecznej wymiany znajdziesz w tekście nowa strona a pozycje w Google.
Jak przejąć projekt bez przerwy w działaniu firmy?
Stary system działa przez całe przejęcie: audyt czyta, nie zmienia; stabilizacja wchodzi poprawkami z oknami serwisowymi; ewentualna migracja jedzie równolegle do dnia przełączenia. Przerwy planuje się na godziny o najmniejszym ruchu i komunikuje z wyprzedzeniem. Ciągłość jest warunkiem projektu, nie życzeniem.
Czy audyt zobowiązuje do dalszej współpracy z wami?
Nie, raport z audytu jest Twój i możesz z nim pójść do dowolnego wykonawcy. Celowo piszemy go tak, żeby był zrozumiały i użyteczny poza nami. Częściej jednak zostaje u nas, bo rekomendacje z kwotami łatwo zweryfikować w praktyce pierwszym etapem.
Po czym poznać, że system trzeba przepisać od nowa?
Po rachunku, nie po emocjach: gdy koszt kolejnych zmian w starym kodzie przewyższa koszt budowy odpowiednika z migracją danych. Sygnały pomocnicze to porzucony framework, brak możliwości aktualizacji bezpieczeństwa i strach zespołu przed dotykaniem czegokolwiek. Decyzja wychodzi z audytu z liczbami po obu stronach. Częsty kompromis wygląda tak: rdzeń zostaje na dożywanie, nowe funkcje powstają obok w zdrowym kodzie, a pełna wymiana czeka na moment, w którym stary system przestanie być potrzebny. Rozłożenie kosztu w czasie bywa ważniejsze niż czystość architektury.
Stan na sierpień 2026 r.
Artykuł ma charakter informacyjny. Kwoty audytów pochodzą z naszego cennika, a każda sytuacja przejęciowa jest inna, dlatego proces zaczynamy od rozmowy i oceny dostępów.
