Zmiana wykonawcy projektu IT – jak to zrobić, jakie są kroki, ile to kosztuje

Zmiana wykonawcy projektu IT to decyzja, która często budzi obawy — szczególnie gdy projekt jest już rozpoczęty, a platforma czy aplikacja działa w środowisku produkcyjnym. Mimo to wiele firm staje przed takim wyborem: zarówno na wczesnym etapie, jak i wtedy, gdy produkt wymaga dalszego rozwoju, a współpraca z obecnym zespołem przestaje się układać. Jeśli zmiana agencji developerskiej to coś, co rozważasz, ten poradnik pomoże Ci przejść przez ten proces. Dowiesz się jakie są dobre praktyki przekazywania projektu IT oraz realne koszty, z jakimi trzeba się liczyć.

Zmiana wykonawcy projektu IT – najczęstsze powody

Z naszego doświadczenia decyzje klientów o zmianie partnera technologicznego niemal zawsze mają konkretne, powtarzające się przyczyny:

• Błędy i problemy techniczne. Najczęstszą przyczyną są powtarzające się bugi, często uniemożliwiające korzystanie z nowych funkcji lub blokujące publikację kolejnych wersji aplikacji (np. z powodu konfliktów w kodzie, braku testów lub złej architektury), lub sprawiające że aplikacja otrzymuje negatywne recenzje.
• Problemy z komunikacją. Przykładowo, wykonawca nie poinformował klienta o estymacjach czasowych czy zmianach zakresu prac; zamiast tego wykonał pewien zakres oprogramowania na własną rękę, a gdy pojawiały się „gotowe” rezultaty, wymagał od klienta zapłaty bez wcześniejszych ustaleń. Wykonawca w takim przypadku podjął decyzję biznesową, która nie należała do jego kompetencji.
• Brak informacji o postępach, gdzie klienci byli całkowicie wyłączeni z procesu – nie wiedzieli, na jakim etapie są prace, a aktualizacje pojawiały się rzadko lub tylko na żądanie.
• Zmiany personalne po stronie wykonawcy, które wstrzymały dalszy rozwój aplikacji. Na przykład, gdy zwolnił się główny programista, który był „filarem” projektu, a agencja nie potrafiła zapewnić odpowiedniego zastępstwa oraz transferu wiedzy. 

Takie doświadczenia klientów nie tylko wpływają na ich decyzję o zmianie wykonawcy, ale też sprawiają, że na etapie przejęcia oczekują od nowego partnera dużo lepszej komunikacji, transparentności oraz kompetencji technicznych — i my zawsze stawiamy to na pierwszym miejscu.

Dlaczego możesz zwlekać z decyzją o zmianie wykonawcy?

Brak świadomości, że można lepiej

Być może nie wiesz, jak powinna wyglądać naprawdę dobra współpraca z wykonawcą. Jeśli nie masz punktu odniesienia, możesz akceptować niską jakość kodu, słabą komunikację czy opóźnienia, uznając to za „branżową normę”.

Obawa przed dużymi kosztami zmiany

Możesz zakładać, że przejęcie projektu przez nowy zespół będzie bardzo kosztowne i czasochłonne – zanim to realnie zweryfikujesz. To naturalna obawa, ale często nie ma pokrycia w faktach.

Obawa przed czasochłonnością z powodu braku dokumentacji

Jeśli dotychczasowa dokumentacja była słaba albo jej brakuje, możesz myśleć: „nowy zespół i tak się w tym nie połapie”. Tymczasem właśnie brak dokumentacji to często jeden z najlepszych argumentów za zmianą – doświadczone firmy potrafią sobie z tym radzić (np. robiąc audyt kodu i odbudowując dokumentację od podstaw).

Niepewność, jak w ogóle zacząć

Możesz nie wiedzieć, jakie kroki podjąć, żeby zmiana wykonawcy była bezpieczna i skuteczna. Jeśli brakuje ci wiedzy technicznej lub jasnego procesu, łatwo o paraliż decyzyjny.

Przywiązanie do obecnego zespołu lub relacji

Czasem trudno ci podjąć decyzję z powodów miękkich – lojalności wobec obecnego partnera, niechęci do konfrontacji, czy nadziei, że jeszcze się „ułoży”.

Gdzie znaleźć solidnego wykonawcę, który przejmie projekt?

Solidnego wykonawcę do przejęcia projektu IT warto szukać przede wszystkim przez rekomendacje zaufanych firm oraz opinie na branżowych portalach, takich jak Clutch – to miejsca, gdzie szybko zweryfikujesz doświadczenie oraz reputację software house’ów. 

Ważne jest jednak, by wybrany partner posiadał specjalizację dokładnie w tych technologiach i językach, w których stworzona została Twoja aplikacja. Tylko wtedy będzie w stanie rzetelnie ocenić jej obecny stan, rozpoznać potencjalne ryzyka i poprowadzić projekt w sposób, który umożliwi długofalową, bezproblemową współpracę.

O co zapytać potencjalnego wykonawcę?

• Czy przejmowali już istniejące projekty? W jakich technologiach?
• Jak wygląda u nich proces audytu i wdrożenia?
• W jaki sposób testują aplikację przed publikacją?
• Jak wygląda u nich komunikacja z klientem?
• W jaki sposób rozliczają się z klientem?
• Czy pracują w modelu agile? Jak planują sprinty?
• Jak dokumentują projekt i zapewniają utrzymanie wiedzy?
• Czy zapewniają wsparcie długoterminowe tzw. maintenance lub SLA i na jakich zasadach?

Zmiana wykonawcy projektu IT – krok po kroku

Jeśli decyzja została już podjęta, oto etapy, które dzielą cię od zmiany wykonawcy oprogramowania:

Krok 1: Ustal status projektu i zabezpiecz dostępy

Zanim zmienisz wykonawcę, upewnij się, że masz pełną kontrolę nad projektem. Zgromadź dokumentację techniczną (architektura, API, baza danych) i funkcjonalną (np. user stories). Sprawdź, gdzie znajduje się kod – najczęściej będzie to repozytorium w GitHub, GitLab lub Bitbucket.

Zabezpiecz dostęp do wszystkich narzędzi:

• serwerów (np. AWS, OVH),
  
• środowisk CI/CD (np. Jenkins, GitHub Actions),
  
• systemów komunikacji i zarządzania projektem (Slack, Jira),
  
• baz danych, kont Google/Firebase, paneli analitycznych.
  

Upewnij się, że Twoja firma ma dostęp administracyjny do wszystkich usług i kont, a nie tylko wykonawca. Zrób kopie zapasowe kodu, konfiguracji i dokumentacji.

Krok 2: Audyt projektu i kodu

Nowy wykonawca potrzebuje pełnego obrazu sytuacji – zanim przejmie odpowiedzialność za aplikację, musi dokładnie zrozumieć, z czym ma do czynienia.

Przekaż:

• dostęp do repozytorium z kodem źródłowym (po podpisaniu NDA),
  
• dokumentację techniczną i funkcjonalną,
  
• informacje o infrastrukturze (DNS, certyfikaty SSL, DevOps, środowiska staging/prod),
  
• kontakt do kluczowych osób (biznes, technika, poprzedni zespół).
  

Audyt może mieć różny poziom szczegółowości. Zwykle nowy wykonawca rozpoczyna od ogólnej analizy, której celem jest sprawdzenie, czy projekt nadaje się do dalszego rozwoju w obecnym stanie.

Bardziej szczegółowy audyt obejmuje ocenę jakości kodu, architektury systemu, testów, zabezpieczeń oraz potencjalnych ryzyk technicznych. 

Na tej podstawie otrzymasz raport z rekomendacjami: co warto poprawić, co można zostawić bez zmian, a co wymaga przebudowy.

Krok 3: Rozliczenie z obecnym wykonawcą

• Sprawdź zapisy w umowie (wypowiedzenie, prawa autorskie, przekazanie kodu i dokumentacji).
  
• Rozwiąż współpracę zgodnie z warunkami.
  
• Ustal harmonogram przekazania kodu, dostępów, kont i własności (np. Firebase, App Store).
  
• Rozlicz się finansowo.
  

Krok 4: Formalna zmiana wykonawcy projektu IT – podpisanie umowy

Podpisz umowę, która jasno określa:

• zakres i cele prac,
  
• odpowiedzialności zespołów,
  
• model rozliczeń (np. Time & Materials, fixed price),
  
• SLA, zasady komunikacji i raportowania,
  
• przeniesienie praw autorskich
  

Krok 5: Transfer wiedzy i rozpoczęcie współpracy

• Zorganizuj warsztat przekazania wiedzy – najlepiej z udziałem obu zespołów.
  
• Przekaż kod, dokumentację, dane logowania i instrukcje.
  
• Wyznacz jedną osobę decyzyjną po swojej stronie, która będzie głównym kontaktem dla Project Managera nowego zespołu.
  
• Ustal narzędzia i rytm współpracy: statusy, sprinty, standupy, raportowanie.

Na co zwrócić uwagę i przed czym się wystrzegać:

• Nie pozwalaj na sytuację: „oczywiście, że przejmiemy development”, jeśli nowy wykonawca nie miał jeszcze możliwości szczegółowego zapoznania się z kodem, dokumentacją i specyfiką projektu!
• Uczciwy wykonawca zechce przeprowadzić własny audyt kodu przed deklaracją jakichkolwiek terminów czy kosztów. Brak takiej inicjatywy to sygnał ostrzegawczy.
• Strzeż się ofert naprawy projektu „od jutra” – to nierealistyczne przy złożonych wdrożeniach.
• Uważaj na propozycje „szybkiego przejęcia” bez umowy NDA oraz bez uzgodnienia warunków przejęcia praw autorskich czy własności kodu.
• Dopilnuj, by nie przekazywać jeszcze środowisk produkcyjnych, zanim formalności, przekazanie dokumentacji i rozliczenie z poprzednim partnerem nie zostaną zamknięte.
• Ustal precyzyjnie zakres audytu oraz procesu transferu wiedzy – najlepiej pisemnie.

Ile kosztuje zmiana wykonawcy projektu IT?

Ceny różnią się zależnie od skali i złożoności projektu:

Element kosztowy	Przykładowy zakres kosztów
Audyt obecnego kodu i dokumentacji	4,800–8,000 zł* *Niektóre firmy mogą zaproponować darmowy, wstępny audyt, aby ocenić ogólną jakość kodu.
Warsztaty i wdrożenie tzw.  knowledge transfer (wdrożenie zespołu nowego wykonawcy)	1,600–2,400 zł
Migracja i rekonfiguracja środowisk	3,200–4,800 zł** **O ile konieczna jest zmiana hostingu. Koszt nie będzie występował o ile projekt jest hostwany na Twoich kontach w Chmurze, którymi możesz zarządzać lub w Twojej infrastrukturze serwerowej.

Całkowity transfer, w zależności od projektu, to zwykle 6,400–15,200zł (bez kosztów dalszego rozwoju).

Co grozi, jeśli nie zmienisz wykonawcy mimo problemów?

Decyzja o pozostaniu przy nieskutecznym lub niedostępnym zespole często wynika z obaw przed zmianą. Warto jednak zastanowić się, jakie ryzyko ponosi Twoja firma, jeśli nic z tym nie zrobisz:

1. Narastające koszty utrzymania

Im bardziej przestarzały lub chaotyczny kod, tym droższe będzie jego utrzymanie. Każda zmiana zajmuje więcej czasu, a nowe funkcje łatwo psują stare.

2. Uzależnienie od jednej osoby lub firmy

Jeśli tylko jeden wykonawca zna Twoją aplikację, Twoja firma staje się zakładnikiem jego dostępności, kompetencji i dobrej woli. Dobra praktyka to zawsze dbać o to, by wiedza o systemie była udokumentowana. W przeciwnym wypadku nowi programiści lub firmy zewnętrzne będą mieć trudności z wejściem w projekt bez lub wiedzy, która istnieje tylko „w głowie” jednej osoby.

3. Trudności w dalszym rozwoju

Brak dokumentacji, dług technologiczny lub błędy architektoniczne mogą całkowicie zablokować rozwój produktu. Zmiana wykonawcy projektu IT jest wskazana, jeśli obecna agencja nie chce uporządkować i naprawić oprogramowania.

4. Ryzyko utraty danych lub kontroli nad aplikacją

Brak dostępu do repozytorium, kodu, serwerów czy kont w chmurze to realne zagrożenie dla ciągłości działania biznesu.

W wielu przypadkach to nie zmiana wykonawcy jest ryzykowna — tylko pozostanie przy obecnym.

Czy każda wada aplikacji oznacza, że trzeba zmienić agencję developerską?

Nie. Nawet najlepszy zespół IT nie stworzy aplikacji całkowicie wolnej od błędów. Błędy, niedoskonałości czy pomniejsze problemy techniczne zdarzają się w każdym projekcie – to naturalny element procesu tworzenia oprogramowania. Kluczowe jest nie to, czy błędy się pojawiają, ale jak szybko i skutecznie są identyfikowane, zgłaszane i rozwiązywane.

Co jest normalne i akceptowalne?

• Błędy wykrywane na etapie testów, które są sprawnie poprawiane przed publikacją wersji produkcyjnej.
  
• Zadanie, które miało zająć 8h, ostatecznie wymaga 16h – bo kod okazał się bardziej skomplikowany lub odkryto powiązane zależności. Zespół komunikuje to z wyprzedzeniem, podaje przyczyny i wspólnie z klientem podejmuje decyzję, czy i jak kontynuować.
  
• Regularna konieczność refaktoru, czyli przebudowy fragmentów kodu, by zwiększyć jego czytelność lub wydajność.
  
• Zmiany wymagań, które wpływają na zakres prac i wymagają elastyczności po obu stronach.

Dobry zespół software’owy nie unika problemów, tylko je komunikuje, dokumentuje i rozwiązuje w przewidywalny sposób.

Gwarancja – w jakim zakresie jest możliwa przy zmianie wykonawcy?

To zupełnie zrozumiałe, że po negatywnych doświadczeniach z poprzednim wykonawcą chcesz się zabezpieczyć i oczekujesz gwarancji. Nowy wykonawca z reguły nie udzieli gwarancji na bezbłędne działanie całego systemu, jeśli wcześniej tworzyła go inna firma, ponieważ nie ponosi odpowiedzialności za jakość istniejącego kodu. Może jednak zaoferować gwarancję szybkiej reakcji i wsparcia przy napotkanych problemach, a także objąć gwarancją te elementy, które sam stworzy lub poprawi w ramach umówionych prac. 

Podsumowanie

Zmiana wykonawcy projektu IT to trudna, ale często konieczna decyzja. Warto podejść do niej jak do inwestycji w przyszłość – z chłodną głową, konkretnym planem i wsparciem doświadczonego partnera. Dobrze przeprowadzony proces pozwala nie tylko odzyskać kontrolę nad aplikacją, ale też otwiera drogę do jej dalszego rozwoju.