Umowa z wykonawcą oprogramowania nie jest po to, żeby wisieć w segregatorze, tylko po to, żeby odpowiadać na trudne pytania, zanim się pojawią. Kto jest właścicielem kodu? Co znaczy "skończone"? Co się dzieje, gdy współpraca się psuje? Poniżej zapisy, o które pytaj, oraz sygnały, przy których lepiej poszukać innego wykonawcy. Piszemy to z pozycji firmy, która takie umowy podpisuje po drugiej stronie stołu.
Prawa do kodu: zapis, od którego zaczynaj czytanie
Najdroższy błąd w umowach IT to przemilczane prawa autorskie. Bez wyraźnego przeniesienia praw majątkowych kod pozostaje własnością wykonawcy, a Ty płacisz za licencję na własny system. Szukaj zapisu o przeniesieniu autorskich praw majątkowych na wymienionych polach eksploatacji, z prawem do modyfikacji i zlecania zmian osobom trzecim. Samo słowo "licencja" zamiast "przeniesienie" zmienia Twoją pozycję o sto osiemdziesiąt stopni.
Dopilnuj też dostępu do repozytorium kodu w trakcie prac, nie dopiero po zakończeniu. Repozytorium u Ciebie albo z Twoim kontem właściciela to polisa na wypadek, gdyby wykonawca zniknął w połowie.
Zakres: załącznik ważniejszy niż paragrafy
Spory o pieniądze prawie zawsze są sporami o zakres. Umowa powinna wskazywać konkretny dokument: spis funkcji z wyceny, jako definicję tego, co powstaje. Zmiany zakresu dostają wtedy jasną ścieżkę: nowa funkcja, nowa wycena, Twoja akceptacja przed pracą. Jak taki spis powstaje po stronie wyceny, opisaliśmy w artykule o kosztach aplikacji webowej.
Zapisy do sprawdzenia punkt po punkcie
| Zapis | Po co jest | Ryzyko, gdy go brakuje |
|---|---|---|
| Przeniesienie praw majątkowych do kodu | System jest Twój po zapłacie | Płacisz za licencję na własny produkt |
| Harmonogram z etapami i odbiorami | Widzisz postęp i płacisz za dowiezione | Jedna faktura na końcu i rok czekania |
| Procedura odbioru z terminem na uwagi | Jasno wiadomo, kiedy etap jest przyjęty | Wieczne "jeszcze nie skończone" po obu stronach |
| Kwota i zasady zmian zakresu | Budżet pod kontrolą | Dopłaty odkrywane w trakcie |
| Gwarancja i okres poprawek po starcie | Błędy naprawiane bez faktur | Każda usterka to nowa wycena |
| Wyjście z umowy i przekazanie prac | Rozstanie bez zakładników | Kod i dostępy jako karta przetargowa |
| Poufność i dane osobowe | Dane klientów pod ochroną | Odpowiedzialność RODO bez umownego wsparcia |
Harmonogram i odbiory: rytm zamiast wielkiego finału
Zdrowa umowa dzieli projekt na etapy z osobnymi odbiorami i płatnościami. Każdy etap kończy się działającą częścią systemu, którą testujesz na środowisku roboczym, zgłaszasz uwagi w umówionym terminie i przyjmujesz. Taki rytm chroni obie strony: Ty nie kredytujesz całości w ciemno, wykonawca nie czeka na jedną wielką akceptację, którą łatwo odwlekać.
Odbiór etapu w praktyce
Procedura odbioru, która działa, mieści się w czterech punktach. Etap ląduje na środowisku testowym, do którego masz stały dostęp, a nie na prezentacji. Testujesz na scenariuszach z życia firmy: prawdziwe zamówienie, prawdziwa reklamacja, nie klikanie po ekranach. Uwagi zgłaszasz w umówionym terminie, na przykład pięciu dni roboczych, po którym brak uwag oznacza przyjęcie: bez tego zapisu etapy wiszą w zawieszeniu miesiącami. Poprawki z listy wchodzą bez dopłat, bo mieszczą się w zakresie, a rzeczy spoza listy dostają osobną wycenę. Protokół może być mailem, byle był: przy sporze liczy się ślad, nie pamięć.
Sygnały ostrzegawcze w umowach wykonawców
- Rozliczenie wyłącznie godzinowe bez widełek i bez limitu: budżet bez sufitu.
- Brak słowa o prawach autorskich albo licencja zamiast przeniesienia.
- Kary umowne tylko po Twojej stronie, żadnych terminów po stronie wykonawcy.
- Zakaz zlecania dalszego rozwoju komukolwiek innemu.
- Repozytorium, serwery i domena wyłącznie na kontach wykonawcy.
- Ogólniki w zakresie: "strona internetowa wraz z funkcjonalnościami".
Załączniki, które robią całą robotę
Paragrafy umowy bywają szablonowe, a życie projektu toczy się w załącznikach. Spis funkcji definiuje zakres słowami, które obie strony rozumieją tak samo. Harmonogram z datami etapów zamienia "niezwłocznie" na konkrety. Cennik prac dodatkowych z góry wycenia typowe rozszerzenia, więc zmiana zakresu nie zaczyna negocjacji od zera. Przy systemach webowych, które mają działać nieprzerwanie, dochodzi załącznik o czasach reakcji na awarie po starcie: co znaczy "krytyczne", w ile godzin reagujecie i w jakich godzinach. Braki w załącznikach bolą bardziej niż braki w paragrafach, bo to o nie toczą się codzienne rozmowy.
O czym umowa nie załatwi
Najlepszy papier nie zastąpi dwóch rzeczy: kompetencji wykonawcy i Twojej dostępności do decyzji. Umowa ogranicza szkody, gdy coś idzie źle, ale projekty udają się dzięki jasnemu zakresowi i szybkim odpowiedziom, nie dzięki paragrafom. Dlatego przed podpisem sprawdź realizacje wykonawcy, na przykład tak, jak my pokazujemy swoje w portfolio z liczbami, i przeczytaj o przygotowaniu do rozmowy o wycenie.
Wersja minimum na jedną stronę A4
Jeśli masz zapamiętać z tego tekstu pięć rzeczy do wynegocjowania, brzmią tak. Prawa majątkowe do kodu przechodzą na Ciebie z chwilą zapłaty. Zakres definiuje załączony spis funkcji, a zmiany wchodzą po osobnej wycenie i Twojej akceptacji. Projekt jedzie etapami z odbiorami i płatnością za każdy etap. Po starcie obowiązuje okres poprawek gwarancyjnych w cenie. Repozytorium, domena i serwery są na Twoich kontach albo z Twoim pełnym dostępem od pierwszego tygodnia. Wykonawca, który na te pięć punktów odpowiada wykrętami, oszczędza Ci rozczarowania z wyprzedzeniem.
Najczęściej zadawane pytania o umowę na oprogramowanie
Czy umowa o dzieło wystarczy na projekt IT?
Forma prawna bywa różna: dzieło, świadczenie usług, umowy mieszane przy dłuższej współpracy. Ważniejsze od nazwy są zapisy o prawach do kodu, zakresie i odbiorach. Konstrukcję pod konkretny projekt skonsultuj z prawnikiem, ten tekst nie zastępuje porady prawnej.
Kiedy prawa do kodu przechodzą na zamawiającego?
Tak, jak zapisano w umowie: najczęściej z chwilą zapłaty za etap albo całość. Uczciwy układ wiąże przejście praw z rozliczeniem, nie z widzimisię którejkolwiek strony. Unikaj konstrukcji, w której prawa przechodzą dopiero po zakończeniu wieloletniej współpracy.
Co zrobić, gdy wykonawca znika w trakcie projektu?
Scenariusz na tę okoliczność budujesz przed startem: dostęp do repozytorium od pierwszego tygodnia, dokumentacja uruchomienia, konta serwerów i domeny na Ciebie. Wtedy zniknięcie wykonawcy jest problemem, ale nie katastrofą, bo inny zespół może przejąć prace. O przejmowaniu takich projektów piszemy w osobnym artykule o przejęciach.
Czy kary umowne w umowie IT mają sens?
Mają, jeśli są symetryczne i realistyczne: kara za zwłokę wykonawcy wyważona z terminem Twoich odbiorów i dostarczania materiałów. Kary zaporowe po jednej stronie psują współpracę i bywają podważalne. Lepszą ochroną bywa rytm etapów, w którym opóźnienie widać po dwóch tygodniach, nie po roku.
Kto odpowiada za RODO w budowanym systemie?
Administratorem danych klientów jesteś Ty, a wykonawca zwykle podmiotem przetwarzającym w zakresie prac serwisowych: to wymaga umowy powierzenia. Sam system powinien powstawać zgodnie z zasadą minimalizacji danych i z mechanizmami zgód tam, gdzie są potrzebne. Szczegóły ról rozpisuje się w umowie, a wątpliwości konsultuje z prawnikiem. W praktyce dopilnuj dwóch rzeczy: umowy powierzenia przetwarzania podpisanej z wykonawcą oraz zapisu o tym, co dzieje się z danymi po zakończeniu współpracy. Brak tych dokumentów wychodzi na jaw w najgorszym możliwym momencie, czyli przy kontroli albo incydencie.
Źródła
- Ustawa o prawie autorskim i prawach pokrewnych, tekst jednolity - podstawa przenoszenia praw majątkowych do kodu (Dziennik Ustaw).
- RODO, tekst rozporządzenia - obowiązki przy danych osobowych w systemach (EUR-Lex).
- Urząd Ochrony Danych Osobowych - wytyczne i poradniki dla administratorów danych.
Stan na sierpień 2026 r.
Artykuł ma charakter informacyjny i nie stanowi porady prawnej. Zapisy konkretnej umowy skonsultuj z prawnikiem; my opisujemy praktykę rynkową z perspektywy wykonawcy.
