Umowa na stronę internetową: zapisy, które muszą się znaleźć, żeby nie stracić

Dostałeś projekt umowy od wykonawcy strony internetowej. Przeskanowałeś wzrokiem kilkanaście stron, wydało Ci się, że wszystko jest w porządku - cena, termin, coś o prawach autorskich - i już sięgasz po długopis. Stop. Właśnie w tym momencie większość ludzi wpada w kłopoty, które wychodzą na jaw dopiero miesiąc po odbiorze projektu albo rok później, gdy chcą zmienić agencję.

Nie jestem prawnikiem ani radcą prawnym - jestem webdeveloperem z 13-letnim doświadczeniem, który przez ten czas widział kilkaset umów (w tym własnych) i pomógł kilku klientom wyjść z projektów, w których brak jednego zdania kosztował ich dziesiątki tysięcy złotych. W tym artykule pokażę Ci siedem zapisów, bez których podpisanie umowy na stronę to loteria, i do każdego dorzucę konkretną pułapkę z życia wziętą.

Zakres prac jako oddzielny załącznik - nie opis ogólny w treści umowy

Najczęstszy błąd, jaki widzę: umowa opisuje przedmiot zamówienia jednym zdaniem w stylu "strona firmowa z podstronami". Każda ze stron wyobraża to sobie inaczej. Ty myślisz o 12 podstronach, formularzu kontaktowym, integracji z Google Maps i wersji angielskiej. Wykonawca wycenił 5 podstron i prostą stronę "O nas".

Jak powinno wyglądać dobre rozwiązanie? Zakres prac jako numerowany załącznik nr 1, z listą: wszystkich podstron z nazwami, funkcji (formularz, slider, newsletter, kalkulator, mapa), technologii (WordPress + konkretny motyw lub custom PHP, WooCommerce jeśli sklep), pola tekstowe do uzupełnienia przez klienta lub pisane przez wykonawcę, oraz co NIE wchodzi w zakres.

Przy projektach, które zamawiam dla klientów, zawsze zaczynam od briefu technicznego, który potem przechodzi dosłownie do umowy jako załącznik. Dzięki temu obie strony mają ten sam dokument - i nie ma miejsca na "ale ja myślałem, że...".

Harmonogram z kamieniami milowymi i karami za opóźnienie

Termin oddania strony zapisany jako "do końca 2025 roku" to nie harmonogram - to pobożne życzenie. Dobra umowa dzieli projekt na etapy z datami i kwotami płatności przypiętymi do każdego z nich.

Kara umowna za opóźnienie to element, z którego wykonawcy najchętniej rezygnują. Standardowy rynek (opieram się tu na kilkudziesięciu umowach, które widziałem w Polsce w ostatnich kilku latach) operuje stawką 0,1-0,5% wartości netto za każdy dzień roboczy opóźnienia po terminie. Przy projekcie za 8 000 zł netto i stawce 0,2% daje to 16 zł dziennie - mało, ale mobilizujące. Górny limit 10-20% całości to zabezpieczenie dla obu stron.

Pułapka: umowy bez kary za opóźnienie od strony klienta. Jeśli to Ty nie dostarsz treści, zdjęć czy zatwierdzeń na czas, wykonawca ma prawo przesunąć termin. Dobre umowy to uwzględniają - i słusznie, pod warunkiem że terminy po stronie klienta też są konkretne, a nie rozmyte.

Przeniesienie majątkowych praw autorskich do kodu i grafiki

To najważniejszy prawnie zapis całej umowy i jednocześnie ten, który najczęściej jest napisany niechlujnie lub w ogóle go nie ma.

Polskie prawo (art. 53 ustawy o prawie autorskim i prawach pokrewnych) mówi wprost: przeniesienie majątkowych praw autorskich wymaga formy pisemnej pod rygorem nieważności. Jeśli tego zapisu nie ma, albo jest w emailu, albo "omówiliśmy to ustnie" - prawa zostają u wykonawcy. Ty masz licencję do używania strony, ale nie możesz jej zmodyfikować, odsprzedać ani przekazać innemu wykonawcy bez zgody twórcy.

Co powinno znaleźć się w zapisie o prawach autorskich:

Pułapka, na którą natrafiłem kilkakrotnie: wykonawca używa motywu premium (np. kupionego na Envato za 60 dolarów) i twierdzi, że "przeniósł prawa". Nie może - bo sam ma tylko licencję, nie własność. W umowie musi się znaleźć lista komponentów stron trzecich z podaniem, na jakiej licencji działają (GPL, MIT, CC) i czy możesz je modyfikować oraz przekazywać dalej.

Więcej o tym, kto naprawdę jest właścicielem strony po projekcie, opisałem w artykule kto jest właścicielem strony - kod, domena, dane.

Przekazanie domeny, hostingu i wszystkich dostępów

To punkt, który często w ogóle nie pojawia się w umowie - bo wykonawca zakłada, że "to oczywiste", a klient nie wie, że ma o to pytać. A potem projekt jest skończony, faktura zapłacona i nagle okazuje się, że domena jest zarejestrowana na agencję, a hosting też.

Moja rekomendacja, którą stosuję wobec wszystkich klientów: domena na Ciebie od pierwszego dnia, hosting płacony przez Ciebie bezpośrednio (lub przez agencję, ale na Twoim koncie). Agencja dostaje dostęp techniczny (konto FTP, panel hostingowy), ale właścicielem konta jest klient.

Co powinno trafić do umowy: termin przekazania dostępów (np. do 5 dni roboczych od odbioru końcowego), lista konkretnych dostępów (panel domeny z kodem AUTH/EPP, login/hasło FTP lub SFTP, dane phpMyAdmin lub eksport bazy danych, login do panelu administracyjnego WordPress z rolą administratora, dostęp do kont email, klucze API zewnętrznych integracji jeśli płacone przez klienta).

Liczba i zasady poprawek

Brak limitu poprawek to pułapka działająca w obie strony. Klient może żądać bez końca drobnych zmian i blokować projekt. Wykonawca może twierdzić, że każda zmiana po pierwszej jest już "extra". Żadna ze stron nie jest zadowolona, a projekt się nie kończy.

Standard, który stosuję i który widzę w dobrych umowach: 2-3 rundy bezpłatnych poprawek na etap graficzny (projekt, makiety) i 1-2 rundy na etap wdrożeniowy. Każda runda ma formę: klient zgłasza uwagi jednym zbiorczym mailem w terminie X dni, wykonawca implementuje w terminie Y dni. Poprawka to zmiana mieszcząca się w przyjętym zakresie - nie dodawanie nowych funkcji, podstron czy zmiana koncepcji.

Pułapka: "poprawki w rozsądnym zakresie" bez liczby rund i bez definicji, co jest poprawką, a co nowym zakresem. Ten zapis zawsze przegrywa ten, kto płaci - bo to wykonawca będzie interpretował, co jest rozsądne.

Gwarancja i opieka po wdrożeniu

Nikt nie mówi o tym przy podpisaniu umowy, a potem jest awantura. Strona padnie w niedzielę wieczorem przed ważną kampanią, formularz kontaktowy przestanie działać po aktualizacji WordPressa albo sklep przestanie przyjmować płatności po zmianie API u PayU.

Które błędy wchodzą w gwarancję, a które nie? Dobra umowa to rozdziela. Gwarancja obejmuje błędy w dostarczonym kodzie i konfiguracji - czyli to, co wykonawca zepsował lub źle skonfigurował. Nie obejmuje: błędów wynikłych z Twoich własnych modyfikacji, problemów po aktualizacjach wtyczek których nie zatwierdziłeś, awarii serwera po stronie hostingodawcy, zmian w zewnętrznych API (np. PayU zmienia stawki czy adresy endpointów).

Czas reakcji to drugi kluczowy element. "Błędy krytyczne" (strona niedostępna, sklep nie przyjmuje płatności) powinny mieć czas reakcji 24-48h. "Błędy istotne" (jeden formularz nie działa, błąd na konkretnej podstronie) - 3-5 dni. "Poprawki kosmetyczne" - przy najbliższej paczce prac.

Po okresie gwarancji: koniecznie zapisz, czy wykonawca oferuje opiekę płatną i na jakich warunkach, czy możesz samodzielnie modyfikować stronę (tak - jeśli prawa autorskie przeniesione), czy możesz zlecić opiekę komuś innemu.

Zasady rezygnacji i rozwiązania umowy

Mało kto myśli o tym przy podpisaniu, ale to jeden z ważniejszych zapisów - szczególnie przy projektach, które się nie toczą tak jak trzeba.

Co powinno być zapisane: co się dzieje z wypłaconymi zaliczkami przy rezygnacji z winy klienta (zazwyczaj przepadają, ewentualnie rozlicza się etapy), co się dzieje przy rezygnacji z winy wykonawcy (zwrot wpłaconych kwot plus ewentualne odszkodowanie), co klient dostaje, gdy projekt jest w połowie (częściowo wykonane pliki, projekt graficzny, kod w stanie X), ile wynosi termin wypowiedzenia.

Pułapka, na którą kilka razy trafiłem: umowa z zapisem "zaliczka bezzwrotna" bez żadnych wyjątków. Wykonawca bierze 50% z góry, nie robi nic przez 2 miesiące i wtedy twierdzi, że klient nie dostarczył treści (nawet jeśli nie zostały poproszone). Klient traci pieniądze i czas. Dobry zapis mówi, że zaliczka przepada tylko wtedy, gdy opóźnienie wynika udokumentowanie z winy klienta.

Sprawdzenie, czy wykonawca w ogóle jest wiarygodny, zanim podpiszesz jakąkolwiek umowę, to odrębny temat - opisałem go w artykule o czerwonych flagach przy wyborze wykonawcy strony.

Jeden zapis, który jest często pomijany: własność konta Google Analytics i GSC

To nie jest kwestia praw autorskich w sensie klasycznym, ale praktycznie bardzo ważna. Kto zakłada konto Google Analytics 4 i Google Search Console na Twoją domenę? Jeśli robi to agencja na swoim koncie Google i tylko "daje Ci dostęp", to przy zmianie agencji możesz stracić historię danych.

Dotyczy to też: konta Google Tag Manager, Meta Pixel, kont reklamowych Google Ads i Meta Ads (jeśli są zakładane w ramach projektu), integracji z zewnętrznymi narzędziami.

Zapis w umowie: wszystkie konta analityczne i reklamowe zakładane są na adres email klienta lub klient jest właścicielem zasobu i administratorem konta, a wykonawca jedynie dostaje dostęp techniczny.

Jeśli szukasz więcej informacji o tym, jak powinien wyglądać cały proces zamawiania strony od briefu po odbiór, przeczytaj artykuł o kosztach i procesie zamówienia strony internetowej. A jeśli zastanawiasz się, czy w ogóle potrzebujesz nowej strony internetowej czy sklepu - wejdź na stronę usług i napisz.