Umowa na serwis internetowy. 12 klauzul, które decydują, czy zapłacisz za gotowy produkt, czy za chaos.

Twój software house właśnie wysłał maila z gotowym etapem strony. Byłeś na targach, nie odpisałeś przez tydzień. Wracasz – strona wygląda inaczej niż makieta. Problem: etap został bezwarunkowo zaakceptowany. Poprawki? To teraz prace dodatkowe po 250 zł za godzinę.

Tak działa klauzula milczącej akceptacji – i jest w większości umów na budowę serwisu internetowego.

Przeanalizowaliśmy realną umowę na budowę serwisu webowego. Wynik: 12 klauzul, które decydują, czy zapłacisz za gotowy produkt, czy za chaos. W tym artykule rozkładam każdą z nich na czynniki pierwsze – językiem biznesowym, nie prawniczym. Dowiesz się, gdzie zamawiający najczęściej tracą pieniądze, kontrolę nad projektem i prawa do własnej strony. Na końcu znajdziesz checklistę, którą możesz zabrać na spotkanie z wykonawcą.

Zanim przeczytasz dalej – kilka pojęć, które musisz znać

Polskie prawo nie przewiduje odrębnego typu umowy na serwis internetowy. Kontrakty webdev są kwalifikowane jako umowa o dzieło (art. 627 Kodeksu cywilnego) – zobowiązanie do osiągnięcia konkretnego rezultatu – albo jako umowa o świadczenie usług (art. 750 KC) – zobowiązanie do starannego działania. To rozróżnienie wpływa na zasady odbioru, odpowiedzialność za wady i wymagalność wynagrodzenia.

12 klauzul umowy na serwis internetowy, które decydują o powodzeniu projektu

1. Zakres prac i opis przedmiotu umowy

To fundament całej umowy. Jeśli zakres jest opisany ogólnikowo („nowoczesna strona internetowa z formularzem kontaktowym”), każda rozbieżność między Twoją wizją a efektem pracy wykonawcy będzie sporem interpretacyjnym.

Co powinien zawierać opis przedmiotu umowy:

1. Listę funkcjonalności z podziałem na fazy (np. Faza 1: projekt graficzny, Faza 2: kodowanie front-end, Faza 3: integracje)
2. Wymagania niefunkcjonalne – wydajność, responsywność, obsługiwane przeglądarki
3. Wykaz technologii i narzędzi (WordPress, ACF PRO, React itp.)
4. Jasne wyłączenia – co NIE wchodzi w zakres (np. WCAG 2.1, SEO, copywriting)

Brak precyzyjnego opisu to zaproszenie do scope creep – niekontrolowanego rozszerzania zakresu projektu, o czym więcej w punkcie 9.

2. Harmonogram i podział na etapy

Projekt podzielony na fazy z konkretnymi datami daje Ci kontrolę nad postępem prac. Każdy etap powinien kończyć się mierzalnym rezultatem – np. gotowym projektem graficznym w Figma, działającym front-endem na środowisku deweloperskim.

Zwróć uwagę na dwie rzeczy:

1. Warunki wstępne po Twojej stronie – jeśli umowa wymaga dostarczenia projektu graficznego w Figma (desktop + mobile) na 2 dni robocze przed startem, a Ty tego nie zrobisz, start się przesuwa bez winy wykonawcy
2. Konsekwencje przerwy w pracach – przerwa z Twojej przyczyny dłuższa niż 30 dni może generować dodatkową opłatę za „powrót do projektu” w stawkach prac dodatkowych

3. Wynagrodzenie i warunki płatności

Typowy model fazowy wiąże płatności z kamieniami milowymi projektu. Przykładowy rozkład: 30% przy starcie, 30% po akceptacji projektu graficznego, 40% po odbiorze końcowym.

Przy projekcie za 27 400 zł netto stawka za prace dodatkowe na poziomie 500 zł/h oznacza, że 55 godzin prac pozazakresowych podwaja budżet projektu.

4. Milcząca akceptacja etapów

To jedna z najbardziej ryzykownych klauzul dla zamawiającego. Mechanizm wygląda tak: wykonawca zgłasza gotowość etapu, a Ty masz np. 5 dni roboczych na zgłoszenie uwag. Brak reakcji = bezwarunkowa akceptacja.

Polskie orzecznictwo potwierdza skuteczność takich klauzul. Sąd Okręgowy w Warszawie (XXIII Ga 978/20) uznał, że klauzula „5 dni roboczych na zgłoszenie zastrzeżeń, brak zgłoszenia = dzieło przyjęte” jest ważna i skuteczna w relacjach między profesjonalistami. Sąd powiązał milczenie zamawiającego z faktycznym korzystaniem z dzieła.

Co zrobić, żeby się zabezpieczyć:

1. Ustal wewnętrznie, kto w firmie odpowiada za review każdego etapu
2. Ustaw kalendarzowe przypomnienia na 2 dni przed upływem terminu akceptacji
3. Negocjuj termin adekwatny do złożoności projektu – 5 dni roboczych na review strony z 15 podstronami i integracjami to za mało
4. Upewnij się, że klauzula nie pozbawia Cię prawa do zgłaszania wad ujawnionych po odbiorze

Dla odbioru końcowego termin bywa dłuższy – np. 10 dni roboczych. Ale mechanizm działa tak samo: brak reakcji = bezwarunkowa akceptacja całego projektu.

Napisz do nas

5. Prawa autorskie – kiedy strona naprawdę staje się Twoja

Zgodnie z przepisami ustawy o prawie autorskim i prawach pokrewnych, umowa zobowiązująca do przeniesienia autorskich praw majątkowych przenosi prawa z chwilą przyjęcia utworu – chyba że strony postanowiły inaczej. I właśnie to „inaczej” jest standardem w umowach webdev.

Typowa klauzula: prawa autorskie przechodzą na zamawiającego dopiero z chwilą zaksięgowania ostatniej raty. Do tego momentu masz jedynie licencję ograniczoną – np. do testowania na środowisku deweloperskim.

Co to oznacza w scenariuszu sporu:

1. Zapłaciłeś Ratę I i II (łącznie ok. 16 000 zł netto)
2. Serwis działa na środowisku deweloperskim
3. Spór o zakres ostatniej fazy – wstrzymujesz Ratę III
4. Nie masz praw autorskich do kodu – masz tylko licencję testową
5. Wykonawca może zablokować uruchomienie produkcyjne

Dwie rzeczy do wynegocjowania:

1. Przeniesienie praw autorskich wymaga formy pisemnej pod rygorem nieważności – ustne ustalenia o przeniesieniu praw są nieważne
2. Rozważ licencję awaryjną (escrow) na wypadek sporu – depozyt kodu u niezależnego podmiotu, z warunkami wydania określonymi w umowie

Dobra praktyka z negocjacji umów IT: stosuj zasadę „tyle praw, ile realnie potrzeba”. Nie zawsze musisz żądać pełnego przeniesienia praw – czasem wystarczy licencja wyłączna z prawem do modyfikacji i sublicencjonowania. Wyraźnie rozdziel zasady dla komponentów dedykowanych (Twój kod), standardowych (biblioteki wykonawcy) i open-source.

6. Procedura odbioru i protokoły

Odbiór końcowy to moment, w którym formalnie akceptujesz rezultat prac. Dobrze skonstruowana procedura odbioru obejmuje:

1. Zgłoszenie gotowości przez wykonawcę – z dokumentacją (środowisko testowe, instrukcja)
2. Testy akceptacyjne po Twojej stronie – w oparciu o kryteria z umowy
3. Protokół odbioru (jeśli akceptujesz) lub Protokół rozbieżności (jeśli nie)
4. Termin na analizę rozbieżności przez wykonawcę – np. 4 dni robocze na klasyfikację zgłoszonych usterek
5. Prawo do zakwestionowania klasyfikacji – np. 2 dni robocze na sprzeciw wobec zaklasyfikowania wady jako „kosmetycznej”

Kluczowy problem: jeśli klasyfikację usterek (krytyczna / standardowa / kosmetyczna / nowe wymaganie) ustala jednostronnie wykonawca, tracisz kontrolę nad priorytetami napraw. Negocjuj wspólną tabelę kryteriów jako załącznik do umowy.

7. Gwarancja jakości i jej ograniczenia

Typowy okres gwarancji: 12 miesięcy od uruchomienia produkcyjnego. Ale zakres gwarancji bywa węższy, niż się wydaje.

Scenariusz utraty gwarancji: po wdrożeniu sam instalujesz nową wtyczkę WordPress. Wtyczka powoduje konflikt z kodem wykonawcy. Zgłaszasz usterkę gwarancyjną. Odpowiedź: „nieautoryzowana modyfikacja – gwarancja nie obejmuje”. Koszt naprawy: prace dodatkowe.

Dlatego po wdrożeniu prowadź rejestr wszystkich modyfikacji w serwisie. Każda zmiana kodu lub wtyczki przez Ciebie albo osobę trzecią powinna być udokumentowana – żebyś nie stracił gwarancji przez drobną modyfikację.

8. Ograniczenie odpowiedzialności wykonawcy

Standardowa klauzula: odpowiedzialność wykonawcy ograniczona do wysokości wynagrodzenia netto. Dodatkowo: wyłączenie odpowiedzialności za utracone korzyści (lucrum cessans).

To standard rynkowy po stronie wykonawcy, ale możesz negocjować wyjątki. Dobra praktyka: pozostaw bez limitu odpowiedzialności naruszenia praw własności intelektualnej i rażące naruszenia poufności lub bezpieczeństwa. Nawet jeśli ogólny limit odpowiedzialności jest ograniczony do kwoty wynagrodzenia, te kategorie naruszeń powinny być wyłączone z limitu.

9. Klauzula weryfikacji zakresu – ochrona przed niekontrolowanym wzrostem kosztów

To mechanizm zarządzania zmianami w trakcie projektu. Bez niego każda zmiana zakresu to negocjacja od zera – albo, co gorsza, wykonawca realizuje „po swojemu” i wystawia fakturę za prace dodatkowe.

Dobrze skonstruowana klauzula działa tak:

1. Wykonawca identyfikuje rozbieżność między zakresem umowy a rzeczywistą złożonością prac
2. Zgłasza ją pisemnie w ciągu 3 dni roboczych
3. Strony mają 7 dni roboczych na negocjację
4. Do czasu uzgodnienia – prace w spornym zakresie są wstrzymane
5. Prace dodatkowe wymagają pisemnego zlecenia z określonym budżetem

Bez tej klauzuli: projekt graficzny w Figma okazuje się bardziej złożony niż zakładała wycena. Wykonawca albo realizuje uproszczoną wersję, albo żąda dopłaty bez formalnej procedury. Z klauzulą: masz czas na decyzję i kontrolę nad budżetem.

10. Konsekwencje rozwiązania umowy i kary umowne

Kary umowne powinny być narzędziem realnie dyscyplinującym obie strony. Problem pojawia się, gdy są asymetryczne.

Przykład z analizowanej umowy: kara za porzucenie projektu przez wykonawcę to jedynie 5 000 zł – przy projekcie wartym 27 400 zł netto to mniej niż 20% wartości kontraktu. A restart z nowym wykonawcą kosztuje zwykle 30–50% wartości projektu (onboarding, odtworzenie prac, analiza kodu).

Co negocjować:

1. Karę na poziomie min. 15–20% wartości umowy za odstąpienie z przyczyn po stronie wykonawcy
2. Mechanizm escrow kodu źródłowego – żebyś w razie porzucenia projektu miał dostęp do dotychczasowych prac
3. Obowiązek przekazania dokumentacji i kodów źródłowych niezależnie od przyczyny rozwiązania umowy
4. Prawo do dochodzenia odszkodowania uzupełniającego ponad kary umowne

11. Klauzula renegocjacji przy wydłużeniu projektu

Projekty IT się wydłużają. Pytanie: kto za to płaci?

Typowa klauzula: wydłużenie projektu powyżej 4 miesięcy z przyczyn niezawinionych przez wykonawcę uprawnia go do renegocjacji ceny. Brak Twojej zgody w 7 dni = prawo wykonawcy do odstąpienia z zachowaniem wynagrodzenia za wykonane prace.

Warto wiedzieć, że art. 357¹ Kodeksu cywilnego (klauzula rebus sic stantibus – nadzwyczajna zmiana stosunków) ma charakter wyjątkowy. Samo wydłużenie projektu IT nie stanowi automatycznej podstawy do sądowej renegocjacji ceny. Wymagana jest obiektywna, nadzwyczajna zmiana stosunków i groźba rażącej straty. Dlatego umowna klauzula renegocjacji jest ważniejsza niż ustawowa – bo daje obu stronom przewidywalny mechanizm postępowania.

12. Poufność i ochrona danych

Klauzula poufności obowiązuje zwykle 5 lat po zakończeniu umowy. Treść umowy jest z definicji informacją poufną.

Osobna kwestia to RODO – jeśli serwis zbiera dane osobowe (formularze kontaktowe, analityka, newsletter), umowa powinna zawierać:

1. Określenie ról: kto jest administratorem danych, a kto procesorem
2. Umowę powierzenia przetwarzania danych osobowych (art. 28 RODO)
3. Zobowiązanie wykonawcy do usunięcia danych po zakończeniu prac
4. Zasady postępowania w przypadku naruszenia bezpieczeństwa danych

Dostępność cyfrowa – nowy obowiązek od 28 czerwca 2025 r.

Od 28 czerwca 2025 r. obowiązuje ustawa z dnia 26 kwietnia 2024 r. o zapewnianiu spełniania wymagań dostępności (Polski Akt o Dostępności, wdrażający dyrektywę UE 2019/882). Jeśli Twój serwis jest interfejsem usług handlu elektronicznego (sklep internetowy, platforma e-commerce, sprzedaż usług online), musi spełniać wymagania normy EN 301 549 i standardu WCAG 2.1 poziom AA.

Nadzór sprawują: Prezes PFRON, Prezes UKE, Minister Cyfryzacji (dla e-commerce) i Rzecznik Finansowy. Sankcje obejmują decyzje nakazujące usunięcie naruszenia, zakaz świadczenia usług i administracyjne kary pieniężne.

Jeśli zamawiasz serwis z funkcjami e-commerce, uwzględnij wymagania WCAG 2.1 AA w zakresie projektu. Świadome wyłączenie dostępności z zakresu umowy naraża Cię na ryzyko sankcji – i konieczność kosztownej przebudowy serwisu po wdrożeniu.

Checklista przed podpisaniem umowy na serwis internetowy

Zanim podpiszesz umowę z software house’em lub agencją webową, przejdź przez te punkty:

Jak możemy Ci pomóc z umową IT

Przegląd umowy z software house’em lub agencją webową to coś, co robimy regularnie. Znamy typowe pułapki, bo widzimy je w dziesiątkach kontraktów rocznie – od projektów za kilkanaście tysięcy złotych po wdrożenia warte setki tysięcy.

Nasze wsparcie obejmuje:

1. Review umowy przed podpisaniem – wskazujemy klauzule wymagające zmiany, proponujemy konkretne zapisy i pomagamy w negocjacjach z wykonawcą
2. Audyt istniejących umów IT – jeśli masz już podpisaną umowę, sprawdzimy, gdzie są luki i jak je domknąć aneksem
3. Przygotowanie wzorów umów – jeśli regularnie zamawiasz usługi IT, budujemy spójny system umów dopasowany do Twojego modelu działalności
4. Wsparcie w sporach z wykonawcami – od negocjacji polubownych po reprezentację w postępowaniach

Nie tworzymy dokumentów „na zapas” – projektujemy zasady tam, gdzie faktycznie powstaje ryzyko. Łączymy prawo umów z prawem autorskim, RODO i specyfiką branży IT, bo w umowie webdev te obszary się przenikają.

Umowa na serwis internetowy – podsumowanie i następne kroki

Umowa na budowę serwisu internetowego to nie formalność do podpisania „żeby zacząć projekt”. To narzędzie, które decyduje o tym, czy zachowasz kontrolę nad budżetem, harmonogramem i prawami do efektu prac.

12 klauzul opisanych w tym artykule pokrywa sześć kategorii ryzyka kontraktowego: techniczne, organizacyjne, prawne, finansowe, operacyjne i relacyjne. Każda z nich wymaga świadomej decyzji – nie domyślnych ustawień wykonawcy.

Zanim podpiszesz kolejną umowę z software house’em, wyślij ją do review. Konkretne uwagi, zero prawniczego żargonu, termin dopasowany do Twojego harmonogramu. Napisz do nas

Najczęściej zadawane pytania

Czy mogę użyć własnego prawnika do review umowy z software house’em? Tak – i to dobra praktyka. Profesjonalni wykonawcy traktują review prawny jako normalny element procesu. Jeśli software house reaguje negatywnie na propozycję przeglądu umowy przez Twojego prawnika, to sygnał ostrzegawczy. Review umowy IT trwa zwykle 2–5 dni roboczych i pozwala wychwycić klauzule, które mogą Cię kosztować wielokrotnie więcej niż sama usługa prawna.

Czy milcząca akceptacja jest legalna i czy mogę ją zakwestionować po fakcie? Klauzula milczącej akceptacji jest dopuszczalna w relacjach B2B między profesjonalistami – potwierdza to orzecznictwo (wyrok SO w Warszawie, XXIII Ga 978/20). Po upływie terminu możesz nadal zgłaszać wady istotne ujawnione po odbiorze – klauzula nie może Cię tego prawa pozbawić. Wady nieistotne (kosmetyczne) po milczącej akceptacji stają się jednak prace dodatkowe. Dlatego lepiej negocjować realistyczny termin na review niż próbować podważać klauzulę po fakcie.

Ile powinienem budżetować na prace dodatkowe ponad kwotę z umowy? Nie ma jednej reguły, ale przy dobrze zdefiniowanym zakresie rezerwa na poziomie 15–20% wartości umowy jest rozsądna. Przy źle zdefiniowanym zakresie – prace dodatkowe mogą przekroczyć wartość bazowej umowy. Sprawdź stawkę godzinową za prace dodatkowe w umowie – jeśli wynosi 250–500 zł/h, policz, ile godzin dodatkowych prac mieści się w Twoim budżecie.

Czy 12 miesięcy gwarancji to standard rynkowy? 12 miesięcy od uruchomienia produkcyjnego to częsty okres w umowach webdev. Zakres gwarancji bywa jednak węższy niż oczekujesz – obejmuje błędy w kodzie wykonawcy, ale nie problemy wynikające z Twoich modyfikacji, wygasłych licencji zewnętrznych czy zmian w API narzędzi trzecich. Po zakończeniu gwarancji potrzebujesz odrębnej umowy serwisowej lub wewnętrznych zasobów do utrzymania serwisu.

Co się stanie z moją stroną, jeśli software house zbankrutuje w trakcie projektu? Jeśli nie masz przeniesienia praw autorskich (bo nie zapłaciłeś wszystkich rat), możesz utracić dostęp do kodu. Zabezpieczeniem jest escrow kodu źródłowego – depozyt u niezależnego podmiotu (notariusz, wyspecjalizowana firma depozytowa, skrytka bankowa) z określonymi warunkami wydania (np. ogłoszenie upadłości wykonawcy). W Polsce escrow kodu to umowa nienazwana (art. 750 KC), stosowana głównie w większych projektach, ale warto ją rozważyć nawet przy mniejszych wdrożeniach – szczególnie jeśli serwis jest krytyczny dla Twojego biznesu.

Jak negocjować umowę z software house’em, żeby nie zepsuć relacji? Negocjacje umowy to normalny element współpracy – nie sygnał braku zaufania. Skup się na mechanizmach, nie na emocjach: zaproponuj wspólną tabelę kryteriów usterek zamiast jednostronnej klasyfikacji, zaproponuj klauzulę weryfikacji zakresu z terminami dla obu stron, zaproponuj realistyczne terminy akceptacji. Profesjonalny wykonawca doceni partnera, który wie, czego chce – bo jasne zasady ograniczają ryzyko sporu po obu stronach.