Zmiana software house’u przy projekcie średniej wielkości kosztuje od 25 do 120 tysięcy złotych i zajmuje od 6 do 14 tygodni, zanim nowy zespół zacznie pracować w tempie porównywalnym z poprzednim.
Sam audyt kodu przed przekazaniem to zwykle 30-120 godzin pracy, czyli od około 6 do 45 tysięcy złotych przy stawkach, jakie polskie firmy podają publicznie. Odtworzenie brakującej dokumentacji dokłada kolejne 8-30 tysięcy, a nakładanie się okresu wypowiedzenia starego wykonawcy na rozruch nowego oznacza 4-6 tygodni podwójnych faktur. I teraz zdanie, którego nie usłyszysz od żadnego wykonawcy: jeśli Twój roczny budżet na rozwój produktu nie przekracza 150 tysięcy złotych, zmiana software house’u zwykle zjada więcej, niż daje. Taniej wychodzi naprawa relacji, renegocjacja zakresu albo wymuszenie na obecnym zespole dokumentacji i dostępów.
Kluczowe fakty:
- Zmiana software house'u przy projekcie średniej wielkości kosztuje od 25 do 120 tysięcy złotych i zajmuje od 6 do 14 tygodni, zanim nowy zespół osiągnie tempo pracy porównywalne z poprzednim.
- Jeśli roczny budżet na rozwój produktu nie przekracza 150 tysięcy złotych, koszt zmiany wykonawcy zwykle przewyższa potencjalne korzyści – taniej może okazać się renegocjacja warunków z obecnym zespołem.
- Częstym problemem przy zmianie wykonawcy jest brak uregulowania własności kodu – repozytorium może znajdować się na koncie GitHub wykonawcy, a umowa nie zawierać zapisów o przeniesieniu pól eksploatacji.
Napisałem ten tekst, bo widzę tę sytuację regularnie: firma płaci od dwóch lat, produkt stoi, a właściciel dowiaduje się, że repozytorium jest na koncie GitHub wykonawcy, umowa nie wymienia pól eksploatacji, a jedyna osoba znająca architekturę odeszła z projektu w marcu. Wtedy nie ma dobrego wyjścia, są tylko drogie i bardzo drogie.
Co znajdziesz niżej:
- Rozbicie kosztów zmiany wykonawcy na pozycje, które możesz sam policzyć
- Sygnały, po których poznasz, że rozmowy z obecnym zespołem nie mają już sensu
- Trzy przepisy polskiego prawa autorskiego, które decydują o tym, czy kod jest Twój
- Zakres i cena audytu kodu przed zmianą wykonawcy
- Harmonogram przejęcia projektu rozpisany na 10 tygodni
- Dane z bazy 467 polskich firm technologicznych: ilu wykonawców w ogóle wspomina o audycie, dokumentacji i utrzymaniu
- Co dane GitClear za 2026 rok mówią o kodzie pisanym z pomocą AI i dlaczego zmienia to zasady audytu
Ile kosztuje zmiana software house’u i skąd biorą się te kwoty?
Nikt nie wystawi Ci faktury z pozycją „zmiana wykonawcy”. Koszt rozkłada się na kilka strumieni, z których dwa są niewidoczne w budżecie, dopóki nie zaczną boleć: spadek tempa nowego zespołu przez pierwsze tygodnie i czas Twoich ludzi, którzy zamiast pracować, tłumaczą kontekst.
Punktem odniesienia dla stawek są dane z profili firm. Na Clutch, gdzie w sierpniu 2026 roku widnieje ponad 1600 polskich dostawców usług programistycznych, najczęściej deklarowany przedział to 50-99 dolarów za godzinę, przy czym najtańsze firmy podają 25-49 dolarów, a część większych organizacji nie publikuje stawek w ogóle. Przy kursie z 4 sierpnia 2026 roku, czyli 3,75 zł za dolara, wychodzi z tego mniej więcej 190-370 zł za godzinę w paśmie głównym i 95-185 zł w paśmie najtańszym.
Poniżej rozbicie, które możesz przełożyć na własny projekt. Widełki dotyczą systemu o średniej złożoności: aplikacja webowa plus panel administracyjny, kilka integracji zewnętrznych, jedna baza danych, zespół 2-4 osób po stronie wykonawcy.
| Pozycja | Nakład | Koszt orientacyjny | Czy da się pominąć |
|---|---|---|---|
| Audyt kodu i architektury przed przekazaniem | 30-120 h | 6 000 – 45 000 zł | Nie, to jedyna pozycja, która zwraca się zawsze |
| Odtworzenie dokumentacji technicznej | 40-80 h | 8 000 – 30 000 zł | Tylko jeśli stary wykonawca ją dostarczy |
| Obsługa prawna rozstania i nowej umowy | 10-30 h | 3 000 – 15 000 zł | Nie, jeśli sporne są prawa do kodu |
| Nakładanie się okresu wypowiedzenia i rozruchu | 4-6 tygodni | Równowartość 1-1,5 miesiąca podwójnych faktur | Rzadko, wymaga zgody obu stron |
| Obniżona wydajność nowego zespołu | 4-8 tygodni | 30-50% budżetu tego okresu | Nie, można ją tylko skrócić dobrym audytem |
| Migracja infrastruktury, kont, domen, certyfikatów | 15-40 h | 3 000 – 15 000 zł | Nie |
Sumując realistycznie: 25-120 tysięcy złotych. Górna granica dotyczy sytuacji, w której nie masz dokumentacji, nie masz praw do kodu i musisz negocjować przekazanie z wykonawcą, który stracił do Ciebie sympatię.
Jest jeszcze scenariusz gorszy od zmiany wykonawcy, czyli przepisanie systemu od zera. Kosztuje zwykle 60-90% pierwotnego budżetu projektu i bywa uzasadnione, ale spotykam go najczęściej jako wygodną podpowiedź nowego wykonawcy, który po prostu nie chce grzebać w cudzym kodzie. Zanim się na to zgodzisz, zażądaj uzasadnienia w liczbach: ile procent modułów jest do wyrzucenia, ile do refaktoryzacji, ile działa poprawnie.
Co zrobić, gdy software house nie dowozi? Test, który zrobisz w 48 godzin
Zanim wypowiesz umowę, sprawdź, czy problem leży po stronie wykonawcy, czy po stronie zakresu, który zmieniałeś siedem razy. Rozróżnienie jest brutalne, ale konieczne, bo zmiana wykonawcy przy niestabilnym zakresie kończy się dokładnie tak samo, tylko drożej.
Mam prosty test, który da się przeprowadzić w dwa dni robocze i który nie wymaga wiedzy technicznej. Wyślij trzy prośby i zmierz czas odpowiedzi:
- Poproś o dostęp do repozytorium z uprawnieniami właściciela, nie współpracownika. Firma, która pracuje uczciwie, nada Ci je w kilka godzin. Firma, która buduje sobie dźwignię, zacznie tłumaczyć, że „to nasze wewnętrzne środowisko”.
- Poproś o instrukcję uruchomienia projektu na czystej maszynie i o listę zewnętrznych usług, od których zależy działanie systemu. Jeśli odpowiedź brzmi „musi to zrobić Marek, on jedyny to konfigurował”, właśnie poznałeś rozmiar ryzyka.
- Poproś o aktualny diagram architektury i listę znanych długów technicznych. Brak jakiegokolwiek dokumentu po dwóch latach współpracy to nie zaniedbanie, to sposób pracy.
Sygnały, po których widzę, że rozmowy naprawcze nie mają sensu:
- Faktury w modelu godzinowym rosną, a liczba działających funkcji stoi w miejscu przez trzy kolejne miesiące
- Każde wdrożenie na produkcję wymaga obecności jednej konkretnej osoby o nietypowej porze
- Nie istnieje środowisko testowe, zmiany trafiają prosto na produkcję
- Wykonawca odmawia rozmowy o kosztach utrzymania po zakończeniu prac rozwojowych
- W odpowiedzi na pytanie o dokumentację słyszysz, że „kod jest dokumentacją”
To ostatnie zdanie jest w branży żartem od dwudziestu lat i przestało być śmieszne. Kod opisuje, co system robi. Nie opisuje, dlaczego tak, jakie były alternatywy i czego nie wolno ruszać.
Wypowiedzenie umowy wysyłaj dopiero wtedy, gdy masz już podpisaną umowę z nowym wykonawcą i wykonany audyt. Kolejność odwrotna oznacza, że negocjujesz warunki przekazania z pozycji strony, która nie ma dokąd pójść. Piotr Wolniewicz, Redakcja AIPORT.pl
Chcesz czytać więcej treści związanych z AI?
Dodaj AIPORT.pl do preferowanych źródeł Google
Czego nie odda Ci stary wykonawca, jeśli nie masz tego w umowie?
Tu wchodzimy w obszar, na którym najczęściej rozbijają się przejęcia projektów. Polskie prawo autorskie jest w tej sprawie nieprzyjemnie precyzyjne i nie działa na korzyść zamawiającego.
Po pierwsze, forma. Zgodnie z art. 53 ustawy o prawie autorskim i prawach pokrewnych umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności, co oznacza, że bez pisemnego dokumentu przenoszącego prawa zamawiający nie staje się właścicielem praw autorskich do utworu. Zapłacenie faktury nic tu nie zmienia. Umowa zawarta wyłącznie mailowo, bez podpisu kwalifikowanego, nie przenosi praw, a jedynym bezpiecznym odpowiednikiem formy pisemnej przy zawieraniu umów online jest kwalifikowany podpis elektroniczny, którym nie jest profil zaufany.
Po drugie, zakres. Prawa przechodzą wyłącznie na tych polach eksploatacji, które wymieniono w umowie. Ogólnikowy zapis o przeniesieniu „wszelkich praw” bywa uznawany za nieskuteczny. A dla oprogramowania sprawa jest jeszcze węższa, bo art. 74 ust. 4 wymienia jako odrębne uprawnienia zwielokrotnianie programu, tłumaczenie, przystosowywanie, zmianę układu lub jakiekolwiek inne zmiany w programie komputerowym oraz rozpowszechnianie, w tym użyczenie lub najem. Prawo do wprowadzania zmian to osobna pozycja. Jeśli Twoja umowa jej nie wymienia, nowy wykonawca formalnie nie może rozwijać tego kodu.
Po trzecie, wyjątek, o którym mało kto pamięta. Jeżeli umowa nie stanowi inaczej, czynności z art. 74 ust. 4 pkt 1 i 2 nie wymagają zgody uprawnionego, jeżeli są niezbędne do korzystania z programu komputerowego zgodnie z jego przeznaczeniem, w tym do poprawiania błędów przez osobę, która legalnie weszła w jego posiadanie. Czyli nawet na samej licencji możesz naprawiać błędy, o ile umowa Ci tego wprost nie zabrania. Rozwijać o nowe funkcje już nie.
Lista rzeczy, które w praktyce bywają zakładnikiem przy rozstaniu:
- Repozytorium wraz z pełną historią zmian, nie sam zrzut plików
- Konta w usługach chmurowych założone na dane wykonawcy
- Klucze API do integracji zewnętrznych i dostęp do panelu płatności
- Domeny i certyfikaty rejestrowane „dla wygody” przez wykonawcę
- Konfiguracja procesów wdrożeniowych, często jedyna nieudokumentowana wiedza w projekcie
- Zgody podwykonawców i freelancerów na przeniesienie praw dalej
Ten ostatni punkt bywa miną. Software house, który realizował Twój projekt rękami trzech współpracowników na kontraktach B2B, mógł nie zadbać o skuteczne nabycie praw od nich. Wtedy nie ma czego przenosić na Ciebie, nawet w dobrej wierze.
Jak wygląda audyt kodu przed zmianą wykonawcy i ile powinien kosztować?
Audyt kodu przed zmianą wykonawcy to nie jest przegląd stylu programowania. To wycena ryzyka: ile kosztuje utrzymanie tego, co masz, i czy nowy zespół w ogóle jest w stanie to przejąć.
Sprawdziłem, jak często polskie firmy w ogóle oferują taką usługę. W bazie AIPORT.pl, która na 4 sierpnia 2026 roku liczy 467 zweryfikowanych firm technologicznych, o audycie kodu, aplikacji lub technologii wspomina w swoim opisie pięć podmiotów. To 1,07% rynku. Sformułowania „audyt kodu” używa dokładnie jedna firma. Zwrotów „dług technologiczny”, „przegląd kodu” i „kod źródłowy” nie znalazłem w żadnym z 467 opisów.
To nie znaczy, że tej usługi nie da się kupić. Znaczy, że praktycznie nikt jej nie sprzedaje jako produktu, więc pytając o nią, wychodzisz poza standardową ofertę i musisz sam narzucić zakres.
| Obszar audytu | Czego szukać | Nakład |
|---|---|---|
| Historia repozytorium | Kto realnie pisał kod, ile osób, czy nie ma miesięcy ciszy | 4-8 h |
| Pokrycie testami | Odsetek kodu objętego testami, czy testy w ogóle przechodzą | 6-16 h |
| Zależności zewnętrzne | Biblioteki bez wsparcia, wersje po końcu życia, licencje niekompatybilne z komercją | 8-20 h |
| Bezpieczeństwo | Hasła i klucze w kodzie, brak walidacji danych wejściowych, otwarte punkty dostępu | 8-24 h |
| Architektura i duplikacja | Powielone bloki logiki, moduły bez punktów wejścia, brak granic między warstwami | 10-30 h |
| Odtwarzalność środowiska | Czy da się uruchomić projekt na czystej maszynie w jeden dzień | 4-12 h |
| Dokumentacja i wiedza plemienna | Co istnieje wyłącznie w głowach ludzi, którzy odchodzą | 4-10 h |
Efektem audytu ma być dokument, nie prezentacja. Minimum: lista modułów z oceną stanu, wykaz ryzyk uszeregowany według kosztu naprawy, szacunek nakładu na doprowadzenie systemu do stanu, w którym da się go rozwijać, i jasna odpowiedź na pytanie, czy przepisanie od zera byłoby tańsze.
Dwie rzeczy, o których wykonawcy nie mówią. Audyt zamawiaj u kogoś innego niż kandydat na nowego wykonawcę albo przynajmniej rozliczaj go osobno, bo firma, która ma potem dostać zlecenie na rozwój, ma wbudowany interes w pokazaniu, że jest źle. I druga: nie zgadzaj się na audyt darmowy w zamian za zobowiązanie do współpracy. Bezpłatny audyt to narzędzie sprzedażowe, nie diagnostyczne.
Jak przejąć projekt po innym wykonawcy krok po kroku?
Poniżej harmonogram, który sprawdza się przy projektach średniej wielkości. Jest napięty. Jeśli masz komfort czasowy, rozciągnij go, ale nie skracaj.
- Tydzień 1-2. Inwentaryzacja. Spisujesz wszystkie konta, usługi, domeny, repozytoria i umowy. Sprawdzasz, na kogo są zarejestrowane. Weryfikujesz, czy umowa z obecnym wykonawcą przenosi prawa i na jakich polach eksploatacji.
- Tydzień 2-4. Audyt kodu. Równolegle rozmawiasz z kandydatami, ale nie podpisujesz nic przed otrzymaniem raportu.
- Tydzień 4-5. Negocjacje z nowym wykonawcą na podstawie raportu z audytu, nie na podstawie własnego opisu projektu. To zmienia całą dynamikę wyceny.
- Tydzień 5-6. Podpisanie nowej umowy, dopiero potem wypowiedzenie starej. Zabezpieczasz okres przejściowy: konkretną liczbę godzin konsultacji starego zespołu, rozliczanych osobno.
- Tydzień 6-8. Przekazanie techniczne. Nowy zespół uruchamia projekt lokalnie, przechodzi przez wdrożenie na środowisko testowe, dostaje sesje pytań z ludźmi, którzy pisali kod.
- Tydzień 8-10. Pierwsze samodzielne wdrożenie na produkcję przez nowy zespół, jeszcze przy dostępnym starym wykonawcy. To jest moment prawdy.
Jeden warunek odbioru, który zmienia wszystko: nie podpisuj protokołu przekazania, dopóki nowy zespół nie postawi całego systemu na czystej maszynie bez pomocy poprzednika. Ten test wykrywa więcej problemów niż jakikolwiek dokument.
Sensownym zabezpieczeniem jest też zapis o kilkudziesięciu godzinach wsparcia starego wykonawcy w ciągu 60 dni po rozstaniu, płatnych według stawki podwyższonej o 30-50%. Wykonawca chętniej się na to zgadza niż na darmową pomoc, a Ty kupujesz sobie realną możliwość zadania pytania, gdy coś się posypie.
Jak wybrać software house, żeby nie powtórzyć tego samego błędu?
Przeanalizowałem, o czym polskie firmy technologiczne piszą w swoich opisach. Wyniki mówią sporo o tym, na czym rynek koncentruje uwagę, a co przemilcza.
Z 467 firm w bazie AIPORT.pl 324 to software house’y, czyli 69,4%. O utrzymaniu systemu, wsparciu powdrożeniowym lub serwisie wspomina 128 z nich, czyli 39,5%. Znaczy to, że sześciu na dziesięciu wykonawców opisuje siebie wyłącznie przez pryzmat budowania, a nie opiekowania się tym, co zbudowali. O dokumentacji wspomina 9 firm na 467, w tym jeden software house. Umowę serwisową lub SLA wymieniają trzy firmy. Transfer wiedzy: pięć. Depozytu kodu źródłowego nie wspomina żadna.
Pytania, które warto zadać na etapie ofertowania i których większość firm nie usłyszy od innych klientów:
- Kto będzie właścicielem repozytorium od pierwszego dnia i czy zgadzacie się pracować w mojej organizacji na GitHubie
- Jaka jest Wasza stawka za utrzymanie po zakończeniu prac rozwojowych i co dokładnie obejmuje
- Ile osób z Waszego zespołu będzie znało ten projekt na tyle, żeby przejąć go po odejściu głównego programisty
- Jaka dokumentacja powstanie i czy jej dostarczenie jest warunkiem odbioru etapu
- Jak wygląda scenariusz rozstania i ile godzin przekazania jest w nim przewidziane
- Czy korzystacie z narzędzi AI przy pisaniu kodu, w jakim zakresie i jak weryfikujecie to, co wygenerują
Ostatnie pytanie brzmi dziś inaczej niż dwa lata temu i wracam do niego niżej.
Ostrzeżenie, którego nie znajdziesz w materiałach wykonawców: przy budżecie utrzymaniowym poniżej 6-8 tysięcy złotych miesięcznie nie kupujesz gwarancji reakcji, tylko dobrą wolę. Za taką kwotę dostaniesz kilkanaście godzin pracy, co wystarcza na drobne poprawki, ale nie na dostępność w razie awarii w piątek wieczorem. Oferta, która obiecuje SLA z reakcją w godzinę za 3 tysiące miesięcznie, jest po prostu nierzetelna.
Opisz krótko, czego potrzebujesz. Jesteśmy największym HUB-em AI w Polsce — w naszej bazie znajdziesz blisko 500 zweryfikowanych firm specjalizujących się w AI. W Twoim imieniu poprosimy 3-5 dopasowanych wykonawców o kontakt w ciągu 48 godzin.
Czy AI software house to realna kompetencja, czy hasło na stronie?
Sprawdziłem to na tej samej bazie i wynik jest wart chwili uwagi. O sztucznej inteligencji lub uczeniu maszynowym wspomina w swoim opisie 334 firmy z 467, czyli 71,5%. Wśród samych software house’ów jest to 229 z 324, ponad siedem na dziesięć. Ale gdy zawężam kryterium do konkretnych technologii generatywnych, czyli wzmianek o dużych modelach językowych, agentach, GPT czy rozwiązaniach opartych na wyszukiwaniu w dokumentach, zostaje 71 firm w całej bazie, czyli 15,2%. Wśród software house’ów: 25 na 324, niecałe 8%.
Fraza „software house AI” występuje jako słowo kluczowe w profilach 27 firm. Deklaracja jest tania. Rozróżnienie między firmą, która realnie buduje systemy oparte na modelach, a taką, która dopisała AI do opisu, wymaga trzech pytań:
- Który model i w jakiej wersji, oraz co się stanie, gdy dostawca go wycofa albo podniesie cenę
- Jak mierzycie jakość odpowiedzi systemu i jak wygląda zestaw przypadków testowych
- Co się dzieje, gdy model zwróci bzdurę: jest wariant awaryjny, czy użytkownik dostaje halucynację jako fakt
Firma, która nie ma odpowiedzi na drugie pytanie, nie buduje systemów AI, tylko podłącza interfejs do cudzego modelu. To bywa dokładnie tym, czego potrzebujesz, i wtedy nie ma w tym nic złego. Problem zaczyna się, gdy płacisz za drugie, a rozliczasz się jak za pierwsze.
Jeśli chcesz sprawdzić, ilu wykonawców w Twojej okolicy opisuje konkretne kompetencje, cała baza jest otwarta pod adresem aiport.pl/firmy. Warto ją przejrzeć przed rozmową, choćby po to, żeby wiedzieć, ile realnie masz alternatyw.
| Miasto | Firmy w bazie AIPORT.pl | W tym software house’y |
|---|---|---|
| Warszawa | 177 | 120 |
| Wrocław | 76 | 49 |
| Kraków | 53 | 42 |
| Poznań | 35 | 25 |
| Trójmiasto | 29 | 21 |
| Łódź | 12 | 8 |
| Gliwice | 8 | 6 |
| Lublin | 7 | 6 |
| Szczecin | 7 | 5 |
| Rzeszów | 6 | 5 |
| Katowice | 5 | 5 |
| Białystok | 4 | 3 |
Wniosek praktyczny: poza pięcioma największymi ośrodkami liczba lokalnych wykonawców spada do kilku. Jeśli działasz w Kielcach albo Zielonej Górze, upieranie się przy firmie z tego samego miasta zawęża wybór do pojedynczych podmiotów i osłabia Twoją pozycję negocjacyjną. Zdalna współpraca w tej samej strefie czasowej daje kilkadziesiąt razy więcej opcji.
Jak sztuczna inteligencja zmieniła ryzyko przejęcia cudzego kodu?
To jest część, którą dopisałbym do każdego poradnika sprzed dwóch lat. Kod, który przejmujesz w 2026 roku, w dużej części nie został napisany przez człowieka linijka po linijce.
GitClear w raporcie „The Maintainability Gap” przeanalizował 623 miliony zmian w kodzie z lat 2023-2026 i pokazał, że sygnały ponownego wykorzystania kodu spadają: powiązania między plikami zmalały o 35%, przenoszenie linii przy refaktoryzacji o 70%, a długoterminowe utrzymanie starego kodu o 74% wobec poziomu z 2022 roku. Równolegle rośnie kopiowanie i wklejanie wewnątrz commitów o 41%, duplikacja bloków kodu o 81%, konstrukcje maskujące błędy o 47% i dwutygodniowy churn o 15%.
Konkretniej: duplikacja bloków wzrosła z 40,3 do 73,0 na milion zmienionych linii, a odsetek kodu przenoszonego przy refaktoryzacji spadł z 21% w 2022 roku do 3,8% w 2026, podczas gdy kopiowanie i wklejanie wzrosło z 9,4% do 15,7%. Udział zmian dotykających kodu starszego niż rok spadł z 1,7% do 0,46%. Stare warstwy systemu zamarzają i nikt do nich nie wraca, aż coś pęknie.
Autorzy raportu formułują to zresztą ostrożniej, niż robią to nagłówki. Ich teza nie brzmi „AI pisze zły kod”, tylko: dzisiejszy domyślny sposób pracy z AI premiuje kod atomowy, czyli szczęśliwą ścieżkę, przechodzący test i zamknięte zgłoszenie, a po cichu opodatkowuje to, co niewidoczne i odroczone. Rachunek przychodzi w trzecim roku życia produktu. Czyli mniej więcej wtedy, gdy zmieniasz wykonawcę.
Do tego dochodzą deklaracje samych programistów. W badaniu Stack Overflow z 2025 roku odsetek korzystających lub planujących korzystać z narzędzi AI wzrósł do 84%, a jednocześnie nieufność wobec dokładności ich wyników skoczyła z 31% do 46%. Największą bolączką, wskazywaną przez 66% badanych, są rozwiązania „prawie dobre, ale nie do końca”, a 45% przyznaje, że debugowanie kodu wygenerowanego przez AI zjada im poważną część czasu.
Co to zmienia w audycie kodu przed zmianą wykonawcy:
- Duplikacja przestała być drobnym zaniedbaniem stylistycznym, a stała się głównym kosztem utrzymania. Każda poprawka w powielonym bloku wymaga odnalezienia wszystkich jego kopii.
- Trzeba osobno sprawdzać konstrukcje wyciszające błędy, bo system, który nic nie zgłasza, wygląda na zdrowy do dnia awarii.
- Testy przestają być wskaźnikiem jakości, jeśli zostały wygenerowane razem z kodem i sprawdzają dokładnie to, co ten kod robi, łącznie z błędami.
- Pytanie o proces przeglądu kodu jest dziś ważniejsze niż pytanie o technologię.
Jeśli przejmujesz produkt zbudowany w całości metodą „opisz i wygeneruj”, zakładaj górną granicę widełek audytowych, a nie dolną.
Jakie zapisy muszą znaleźć się w nowej umowie?
Ostatnia sekcja jest najbardziej praktyczna, bo dotyczy tego, czy za trzy lata będziesz czytał ten artykuł ponownie.
| Obszar | Zapis bezpieczny | Zapis ryzykowny |
|---|---|---|
| Repozytorium | Kod od pierwszego commita w organizacji zamawiającego | „Przekażemy kod po zakończeniu projektu” |
| Prawa autorskie | Wymienione pola eksploatacji z art. 74 ust. 4, w tym prawo do zmian, forma pisemna lub podpis kwalifikowany | „Przeniesienie wszelkich praw do dzieła” |
| Podwykonawcy | Oświadczenie o skutecznym nabyciu praw od wszystkich współpracowników | Brak wzmianki o podwykonawcach |
| Dokumentacja | Dostarczenie dokumentacji jako warunek odbioru i płatności etapu | „Dokumentacja w miarę potrzeb” |
| Infrastruktura | Konta chmurowe i domeny na dane zamawiającego | Konta zakładane przez wykonawcę „dla wygody” |
| Rozstanie | Określona liczba godzin przekazania, płatna, w terminie 60 dni | Brak jakiejkolwiek klauzuli wyjścia |
| Utrzymanie | Stawka i czas reakcji ustalone przed startem projektu | Wycena utrzymania po zakończeniu prac |
Klauzula wyjścia jest testem charakteru wykonawcy. Firma, która pracuje uczciwie, nie ma powodu jej odrzucać, bo zakłada, że po prostu nie dojdzie do jej zastosowania. Firma, która buduje model biznesowy na uzależnieniu klienta, będzie tłumaczyć, że to zapis nietypowy i niepotrzebny. To akurat prawda, że nietypowy, bo w bazie 467 firm nie znalazłem ani jednej wzmianki o depozycie kodu źródłowego, a o transferze wiedzy piszą tylko pięć podmiotów. Nietypowy nie znaczy jednak niepotrzebny.
Umowa nie jest po to, żeby wygrać spór w sądzie. Jest po to, żeby spór nie miał o co się zaczepić. Dobrze napisany zapis o przekazaniu kosztuje jedno zdanie na etapie podpisywania i oszczędza kilkadziesiąt tysięcy złotych przy rozstaniu. Piotr Wolniewicz, Redakcja AIPORT.pl
FAQ: Pytania i odpowiedzi, czyli to, o co pytacie przed zmianą wykonawcy
Czy mogę zmienić software house w trakcie trwania umowy?
Możesz, ale konsekwencje zależą od zapisów o okresie wypowiedzenia i karach umownych. Standardem w polskich umowach na usługi programistyczne jest wypowiedzenie od 30 do 90 dni. Sprawdź, czy umowa nie zawiera zapisu o zapłacie za pozostałe etapy niezależnie od ich realizacji, bo taki zapis potrafi kosztować równowartość kilku miesięcy współpracy. Jeśli wykonawca nie realizuje umowy, masz podstawę do wypowiedzenia z jego winy, ale wtedy potrzebujesz udokumentowanych wezwań do usunięcia uchybień. Wysyłaj je pisemnie, z terminem, od momentu, w którym zaczynasz rozważać rozstanie.
Ile trwa przejęcie projektu po innym wykonawcy?
Od 6 do 14 tygodni od decyzji do momentu, w którym nowy zespół dowozi samodzielnie. Przy prostych aplikacjach z dobrą dokumentacją bywa szybciej, choć rzadko poniżej miesiąca. Przy systemach bez dokumentacji, z wieloma integracjami i jedną osobą znającą całość, potrafi rozciągnąć się na pół roku. Największym pojedynczym czynnikiem skracającym ten czas jest istnienie działającego środowiska testowego, na którym nowy zespół może się pomylić bez konsekwencji.
Kto powinien zrobić audyt kodu przed zmianą wykonawcy?
Najlepiej podmiot trzeci, który nie kandyduje do prowadzenia projektu. Jeśli nie masz takiej możliwości, zamów audyt u kandydata, ale rozlicz go osobno i poproś o raport w formie, którą mógłbyś pokazać innej firmie. Sam fakt, że raport ma trafić do konkurencji, dyscyplinuje wnioski. Unikaj audytów darmowych powiązanych z obietnicą dalszej współpracy, bo ich funkcją jest sprzedaż, nie diagnoza. Koszt rzetelnego audytu to zwykle 6-45 tysięcy złotych zależnie od rozmiaru systemu.
Co zrobić, gdy software house nie oddaje kodu?
Najpierw sprawdź, co dokładnie mówi umowa o przeniesieniu praw i o wydaniu nośników. Jeśli umowa jest skuteczna, wezwanie od prawnika zwykle wystarcza, bo wykonawca ryzykuje odpowiedzialnością odszkodowawczą. Jeśli umowa nie spełnia wymogu formy pisemnej albo nie wymienia pól eksploatacji, Twoja pozycja jest słaba i realnym wyjściem bywa negocjacja odpłatna. Niezależnie od scenariusza od razu zabezpiecz wszystko, do czego masz dostęp: kopie baz danych, pliki konfiguracyjne, korespondencję projektową.
Czy warto przepisać system od zera zamiast przejmować cudzy kod?
Rzadziej, niż sugerują to nowi wykonawcy. Przepisanie kosztuje zwykle 60-90% pierwotnego budżetu i przez cały ten czas produkt się nie rozwija. Uzasadnione bywa wtedy, gdy technologia nie ma już wsparcia producenta, gdy nie da się uruchomić środowiska albo gdy brak praw autorskich uniemożliwia legalne modyfikacje. Zażądaj od wykonawcy uzasadnienia w liczbach: ile procent kodu jest do wyrzucenia i jaki jest koszt alternatywy w postaci stopniowej wymiany modułów.
Jak sprawdzić software house przed podpisaniem umowy?
Poproś o kontakt do dwóch klientów, z którymi współpraca się zakończyła, a nie tylko do tych aktywnych. Rozmowa z byłym klientem daje więcej niż dziesięć referencji. Sprawdź w KRS, kto stoi za spółką i od kiedy działa. Zapytaj o rotację w zespole w ostatnim roku. I zadaj pytanie o scenariusz rozstania, bo reakcja na nie mówi więcej niż odpowiedź.
Czy software house z AI w nazwie oznacza realną kompetencję?
Nie oznacza niczego. W bazie 467 polskich firm technologicznych o sztucznej inteligencji wspomina 71,5% podmiotów, ale konkretne technologie generatywne wymienia 15,2%, a wśród samych software house’ów niecałe 8%. Rozróżnienie robi się przez pytania o mierzenie jakości odpowiedzi, o wariant awaryjny przy błędzie modelu i o koszt zapytań w skali produkcyjnej. Firma bez odpowiedzi na te pytania nie buduje systemów AI, tylko podłącza interfejs do cudzego modelu.
Ile kosztuje utrzymanie systemu po zakończeniu prac rozwojowych?
Rynkowo od 10 do 20% rocznego kosztu wytworzenia, przy czym dolna granica dotyczy prostych aplikacji bez integracji. W praktyce oznacza to najczęściej od 6 do 25 tysięcy złotych miesięcznie przy systemach dla średnich firm. Poniżej 6 tysięcy kupujesz kilkanaście godzin pracy, a nie gwarancję dostępności. Ustal stawkę utrzymania przed startem projektu, nie po odbiorze, bo po odbiorze nie masz już żadnej dźwigni negocjacyjnej.
Za każdą polską firmą AI stoi konkretny człowiek z imieniem i nazwiskiem, często ten sam w kilku miejscach naraz, i to właśnie ludzie, nie tabelki finansowania, są prawdziwym bohaterem tego artykułu.
Czy da się zmienić wykonawcę bez przestoju w rozwoju produktu?
Da się ograniczyć przestój do 2-3 tygodni, ale całkowite jego uniknięcie wymaga równoległej pracy obu zespołów przez półtora miesiąca, co podwaja koszt tego okresu. Bywa to opłacalne przy produktach, które generują przychód codziennie. Przy projektach wewnętrznych zwykle taniej jest zaakceptować miesiąc zastoju niż płacić podwójnie.
Co z tego zapamiętać, jeśli masz zapamiętać tylko jedną rzecz
Wszystko, co napisałem wyżej, sprowadza się do jednego mechanizmu: koszt zmiany wykonawcy jest odwrotnie proporcjonalny do tego, ile rzeczy trzymasz u siebie. Repozytorium, konta chmurowe, domeny, dokumentacja, prawa autorskie z wymienionymi polami eksploatacji. Każda z tych pozycji przeniesiona na Twoją stronę na etapie podpisywania umowy kosztuje jedno zdanie. Ta sama pozycja odzyskiwana przy rozstaniu kosztuje tygodnie i kilkadziesiąt tysięcy złotych.
Rynek Ci w tym nie pomoże, bo nie ma w tym interesu. Na 467 firm w bazie AIPORT.pl audyt kodu oferuje pięć, o dokumentacji wspomina dziewięć, o depozycie kodu nie wspomina żadna. Sześciu na dziesięciu software house’ów w ogóle nie pisze o utrzymaniu tego, co zbuduje. To nie jest spisek, to jest po prostu asymetria uwagi: sprzedaje się budowanie, nie oddawanie. Dlatego pytania o rozstanie musisz zadać sam, najlepiej zanim ktokolwiek napisze pierwszą linijkę kodu.
I jeszcze jedno, bo dane GitClear za 2026 rok zmieniają tu stawkę. Kod powstaje dziś szybciej, niż kiedykolwiek, ale wiąże się z coraz większą liczbą powielonych bloków, coraz rzadziej sprząta po sobie i coraz rzadziej wraca do starych warstw systemu. Rachunek za to przychodzi w trzecim roku, czyli dokładnie wtedy, gdy większość firm zmienia wykonawcę. Jeśli przejmujesz dziś projekt, przejmujesz też ten rachunek.
Zmiana software house’u nie musi być katastrofą. Bywa najlepszą decyzją, jaką podejmiesz dla produktu. Tylko zrób ją w kolejności: audyt, nowa umowa, wypowiedzenie. Nie odwrotnie.
A teraz Twoja kolej. Zmieniałeś kiedyś wykonawcę? Co okazało się najdroższe: kod, dokumentacja czy ludzie, którzy odeszli razem z wiedzą? Napisz w komentarzu, bo to jest dokładnie ten rodzaj doświadczenia, którego nie znajdzie się w żadnym raporcie. A jeśli znasz kogoś, kto właśnie podpisuje umowę z software housem, podeślij mu ten tekst przed podpisem, nie po. Różnica wynosi mniej więcej pięćdziesiąt tysięcy złotych.
Źródła i metodologia
Artykuł powstał na podstawie własnej analizy bazy 467 polskich firm technologicznych prowadzonej przez redakcję AIPORT.pl (stan na 4 sierpnia 2026, aiport.pl/firmy). Wszystkie odsetki dotyczące oferty firm pochodzą z analizy treści profili i opisują to, co firmy deklarują publicznie, a nie wyniki ankiety o faktycznych praktykach. Dane o jakości kodu pochodzą z raportu GitClear „The Maintainability Gap: AI Code Quality in 2026” obejmującego 623 miliony zmian w kodzie z lat 2023-2026, a dane o zaufaniu programistów do narzędzi AI z Stack Overflow Developer Survey 2025. Przedziały stawek godzinowych oparto na publikowanych profilach polskich dostawców w serwisie Clutch. Podstawy prawne: art. 41, 53, 74 i 75 ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Wykorzystano również dane z raportów Hays Poland IT Contracting oraz Just Join IT. Komentarz redakcyjny i ocena kontekstu branżowego: Piotr Wolniewicz, Redaktor Naczelny AIPORT.pl. Artykuł będzie aktualizowany w miarę zmian na rynku usług programistycznych i pojawiania się nowych danych o jakości kodu tworzonego z udziałem AI.
