Web Application Development Agreement Poland

Umowa o stworzenie aplikacji webowej w Polsce to kontrakt, na podstawie którego wykonawca — agencja software house lub freelancer programista — zobowiązuje się do zaprojektowania i stworzenia aplikacji webowej (systemu, platformy, portalu internetowego, aplikacji SaaS lub systemu zarządzania) zgodnie ze specyfikacją zamawiającego, a zamawiający zobowiązuje się zapłacić wynagrodzenie. Umowa ta jest umową o dzieło w rozumieniu art. 627 Kodeksu cywilnego (ustawa z dnia 23 kwietnia 1964 r., Dz.U. 1964 nr 16 poz. 93 ze zm.) — umową rezultatu — w połączeniu z przepisami ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz.U. 1994 nr 24 poz. 83 ze zm.) dotyczącymi ochrony programów komputerowych.

Umowa o dzieło jest umową rezultatu — wykonawca zobowiązuje się do osiągnięcia konkretnego efektu: stworzenia działającej aplikacji webowej zgodnej ze specyfikacją. Różni się to od umowy starannego działania (zlecenia), gdzie zobowiązanie dotyczy tylko rzetelnego wykonywania pracy. Zamawiającemu przysługuje uprawnienie z rękojmi za wady dzieła (art. 638 Kodeksu cywilnego) — gdy aplikacja ma wady fizyczne (błędy, niezgodność ze specyfikacją) lub prawne (naruszenie praw osób trzecich). Zamawiający może odstąpić od umowy przed jej ukończeniem, płacąc wynagrodzenie za dotychczasowe prace (art. 644 Kodeksu cywilnego).

Kod źródłowy aplikacji webowej stanowi program komputerowy chroniany szczególnym reżimem art. 74 ustawy o prawie autorskim i prawach pokrewnych. Majątkowe prawa autorskie do programu komputerowego stworzonego przez pracownika w ramach stosunku pracy przysługują pracodawcy (art. 74 ust. 3); jednak przy umowie o dzieło lub umowie B2B — prawa należą do wykonawcy, o ile umowa nie stanowi inaczej. Przeniesienie autorskich praw majątkowych do kodu wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim). Na pola eksploatacji programu komputerowego składają się co najmniej: trwałe lub czasowe zwielokrotnianie kodu, tłumaczenie, adaptacja, zmiany układu i wszelkie inne modyfikacje oraz publiczne udostępnianie (art. 74 ust. 4 ustawy o prawie autorskim).

Szczególnym elementem umów na aplikacje webowe jest precyzja specyfikacji funkcjonalnej (scope). Niejasny lub ogólnikowy opis funkcjonalności prowadzi do sporów o zakres — zjawisko znane w branży IT jako scope creep (pełzanie zakresu). Umowa powinna zawierać dokładne opisanie modułów, funkcji, integracji z zewnętrznymi API i wymagań niefunkcjonalnych (wydajność, bezpieczeństwo, dostępność). Harmonogram prac podzielony na kamienie milowe (etapy) z datami odbioru każdego etapu i powiązany z harmonogramem płatności zabezpiecza obie strony: wykonawcę przed nieodebraniem i nieopłaceniem pracy, a zamawiającego przed płatnością za nieukończone etapy.

Wynagrodzenie wykonawcy za stworzenie aplikacji webowej może być ustalone jako wynagrodzenie ryczałtowe (art. 632 Kodeksu cywilnego) za cały projekt — ryzyko wyższych kosztów obciąża wykonawcę — albo jako wynagrodzenie kosztorysowe (art. 629 Kodeksu cywilnego) oparte na nakładzie godzin. Model T&M (Time and Materials) z rozliczeniem godzinowym jest popularny przy zwinnym (agile) podejściu do projektu. Do wynagrodzenia netto dolicza się podatek VAT 23% zgodnie z ustawą z dnia 11 marca 2004 r. o podatku od towarów i usług. Harmonogram płatności zazwyczaj wiązany jest z kamieniami milowymi projektu.

Aplikacja webowa przetwarzająca dane osobowe użytkowników wymaga umowy powierzenia przetwarzania danych osobowych zgodnie z art. 28 rozporządzenia (UE) 2016/679 (RODO), gdy wykonawca w fazie tworzenia lub testowania uzyskuje dostęp do danych osobowych. Nadzór nad stosowaniem RODO w Polsce sprawuje Prezes Urzędu Ochrony Danych Osobowych (PUODO).

Umowa o stworzenie aplikacji webowej w Polsce jest niezbędna w każdej sytuacji, gdy zamawiający zleca zewnętrznemu wykonawcy zaprojektowanie i stworzenie aplikacji webowej, systemu SaaS, portalu, platformy B2B lub systemu zarządzania.

Start-up tworzący produkt SaaS. Firma tworząca nowy produkt SaaS (oprogramowanie jako usługa) zleca agencji lub freelancerowi stworzenie platformy. Umowa precyzuje scope, tech stack, harmonogram, prawa autorskie do kodu i warunki gwarancji.

System wewnętrzny dla przedsiębiorstwa. Firma zamawiająca system zarządzania (CRM, ERP, WMS, HRIS) lub narzędzie wewnętrzne potrzebuje umowy określającej modele danych, integracje z istniejącymi systemami i warunki przeniesienia kodu.

Portal e-commerce lub marketplace. Sklep lub platforma marketplace z funkcjonalnościami wykraczającymi poza standardowe rozwiązania (WooCommerce, PrestaShop) wymaga umowy na dedykowaną aplikację webową.

Aplikacja webowa z danymi osobowymi. Każda aplikacja webowa przetwarzająca dane osobowe użytkowników (dane rejestracyjne, dane transakcyjne, pliki cookies) wymaga umowy powierzenia przetwarzania danych zgodnie z art. 28 RODO, gdy wykonawca ma dostęp do danych w fazie tworzenia lub testowania.

Integracja z API zewnętrznych usług. Aplikacje webowe integrowane z zewnętrznymi API (Stripe, PayU, Twilio, OpenAI) wymagają umowy precyzującej zakres integracji, odpowiedzialność za awarie API zewnętrznych i zasady aktualizacji integracji.

Migracja lub rebuild istniejącej aplikacji. Gdy firma przebudowuje istniejącą aplikację webową (legacy system) lub migruje ją na nowy tech stack, umowa reguluje zakres migracji, prawa do nowego kodu i warunki równoległego działania starych i nowych systemów.

Umowa o stworzenie aplikacji webowej w Polsce powinna zawierać następujące elementy.

Oznaczenie stron. Pełne dane zamawiającego i wykonawcy. Weryfikacja w Krajowym Rejestrze Sądowym (KRS) lub Centralnej Ewidencji i Informacji o Działalności Gospodarczej (CEIDG).

Specyfikacja funkcjonalna (scope). Dokładny opis aplikacji: moduły, funkcjonalności, typy użytkowników, integracje z zewnętrznymi API, wymagania niefunkcjonalne (wydajność, bezpieczeństwo, dostępność WCAG). Specyfikacja powinna być dołączona jako załącznik nr 1. forms-legal.com zaleca, aby specyfikacja była na tyle szczegółowa, by wykluczała dowolną interpretację zakresu.

Stos technologiczny (tech stack). Wskazanie technologii frontendowych, backendowych, bazy danych i infrastruktury hostingowej. Uzgodnienie tech stacku chroni zamawiającego przed narzucaniem technologii utrudniających późniejsze utrzymanie lub zmianę wykonawcy.

Harmonogram i kamienie milowe. Podział projektu na etapy z datami odbioru każdego etapu. Powiązanie harmonogramu płatności z kamieniami milowymi — płatność po odbiorze każdego etapu. Procedura odbioru etapu i zgłaszania zastrzeżeń.

Wynagrodzenie. Model wynagrodzenia: ryczałt (art. 632 KC) lub T&M godzinowo (art. 629 KC). Harmonogram płatności. VAT 23%. Odsetki ustawowe za opóźnienie (art. 481 KC) i rekompensata z ustawy o przeciwdziałaniu nadmiernym opóźnieniom w transakcjach handlowych.

Prawa autorskie do kodu. Przeniesienie autorskich praw majątkowych do kodu źródłowego (forma pisemna pod rygorem nieważności — art. 53 ustawy o prawie autorskim) lub licencja. Pola eksploatacji programu komputerowego (art. 74 ust. 4 i art. 50 ustawy o prawie autorskim): zwielokrotnianie, adaptacja, modyfikacja, udostępnianie. Przekazanie kodu w repozytorium Git. Obowiązek dokumentowania użytych komponentów open source i ich licencji.

Gwarancja. Czas trwania gwarancji na błędy aplikacji po wdrożeniu (zazwyczaj 3–12 miesięcy). Definicja błędu, tryb zgłaszania i czas naprawy.

Poufność i RODO. Klauzula poufności chroniąca specyfikację i dane dostępowe (art. 11 ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji). Umowa powierzenia przetwarzania danych osobowych (art. 28 RODO) gdy wykonawca ma dostęp do danych produkcyjnych lub testowych. Nadzór PUODO (Prezes Urzędu Ochrony Danych Osobowych).

Właściwość sądu. Sąd rejonowy lub okręgowy zgodnie z art. 17 Kodeksu postępowania cywilnego.

Umowa o stworzenie aplikacji webowej w Polsce wypełniana jest krokami.

Krok 1 — oznacz strony. Wpisz pełne dane zamawiającego i wykonawcy. Zweryfikuj w KRS lub CEIDG.

Krok 2 — opisz aplikację (scope). Wpisz dokładny opis funkcjonalności, modułów i integracji. Przygotuj szczegółową specyfikację jako załącznik do umowy — im bardziej precyzyjny opis, tym mniejsze ryzyko sporów o zakres.

Krok 3 — wskaż tech stack. Wpisz technologie frontendowe, backendowe, bazę danych i infrastrukturę hostingową. Uzgodnij, czy kod będzie przechowywany w repozytorium zamawiającego (GitHub, GitLab) czy wykonawcy.

Krok 4 — ustal harmonogram i kamienie milowe. Podziel projekt na etapy z konkretnymi datami odbioru. Każdy etap powinien być mierzalny — np. „uruchomienie API endpointów do listy zadań, zadań użytkownika i uprawnień".

Krok 5 — wpisz wynagrodzenie. Podaj całkowite wynagrodzenie netto i harmonogram płatności powiązany z kamieniami milowymi. Wskaż VAT 23% i termin wystawienia faktury po każdej transzy.

Krok 6 — ureguluj prawa autorskie. Wybierz przeniesienie praw (forma pisemna pod rygorem nieważności — art. 53 ustawy o prawie autorskim) lub licencję. Wymień pola eksploatacji kodu: zwielokrotnianie, adaptacja, modyfikacja, udostępnianie (art. 74 ust. 4 ustawy o prawie autorskim). Wskaż obowiązek przekazania kodu w repozytorium Git.

Krok 7 — ustal warunki gwarancji. Wpisz czas gwarancji (np. 6 miesięcy od wdrożenia), definicję błędu i czas naprawy.

Krok 8 — zabezpiecz poufność i RODO. Jeżeli wykonawca będzie miał dostęp do danych osobowych użytkowników (np. bazy danych testowej), zawrzyj umowę powierzenia przetwarzania zgodnie z art. 28 RODO. Podpisz umowę w dwóch egzemplarzach lub elektronicznie (art. 78[1] KC).

Umowa o stworzenie aplikacji webowej w Polsce podlega przepisom prawa cywilnego, prawa autorskiego i RODO.

Umowa o dzieło i odpowiedzialność. Stworzenie aplikacji webowej jest umową o dzieło (art. 627 KC) — umową rezultatu. Wykonawca odpowiada za wady dzieła (art. 638 KC) i za nienależyte wykonanie zobowiązania (art. 471 KC). Zamawiający może odstąpić przed ukończeniem aplikacji, płacąc wynagrodzenie za dotychczasowe prace (art. 644 KC).

Ochrona programów komputerowych. Kod źródłowy aplikacji webowej jest programem komputerowym chronionym art. 74 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych. Majątkowe prawa do programu stworzonego na zlecenie (nie w stosunku pracy) przysługują wykonawcy, o ile umowa nie stanowi inaczej. Przeniesienie praw wymaga formy pisemnej (art. 53). Pola eksploatacji programu komputerowego: trwałe lub czasowe zwielokrotnianie, tłumaczenie, adaptacja, zmiany, publiczne udostępnianie (art. 74 ust. 4). Prawidłowy zakres pól musi być wskazany w umowie (art. 41 ust. 2).

Open source i licencje. Komponenty open source używane w aplikacji podlegają swoim licencjom (MIT, Apache 2.0, GPL, LGPL). Użycie komponentów na licencji GPL może narzucać obowiązek udostępnienia całego kodu aplikacji na tej samej licencji (copyleft). Wykonawca powinien dokumentować użyte komponenty i ich licencje.

Ochrona danych osobowych. Jeżeli aplikacja przetwarza dane osobowe użytkowników, zamawiający jest administratorem tych danych w rozumieniu RODO. Wykonawca mający dostęp do danych w fazie tworzenia lub testowania jest podmiotem przetwarzającym — konieczna jest umowa powierzenia przetwarzania danych osobowych zgodnie z art. 28 RODO. Nadzór sprawuje Prezes Urzędu Ochrony Danych Osobowych (PUODO). Naruszenie RODO grozi karą do 20 000 000 euro.

Kary umowne i odpowiedzialność. Strony mogą zastrzec kary umowne za naruszenie zobowiązań niepieniężnych (art. 483 KC): opóźnienie w dostarczeniu etapu, naruszenie poufności. Kara podlega miarkowaniu (art. 484 § 2 KC). Nie zastrzega się kary za zobowiązania pieniężne — na opóźnienie w zapłacie przysługują odsetki (art. 481 KC).

Umowa o stworzenie aplikacji webowej w Polsce bywa wadliwa z powodu kilku powtarzających się błędów.

Błąd 1 — ogólnikowa specyfikacja. Brak precyzyjnego opisu funkcjonalności (scope) prowadzi do scope creep i sporów o to, co jest objęte wynagrodzeniem. Zalecenie: dołącz szczegółową specyfikację jako załącznik; każda funkcjonalność powinna być opisana na poziomie user story lub szczegółowego opisu wymagań.

Błąd 2 — brak przeniesienia praw do kodu. Pominięcie pisemnej klauzuli o przeniesieniu praw autorskich do kodu powoduje, że zamawiający nie nabywa praw do aplikacji, mimo że za nią zapłacił. Przeniesienie praw do programu komputerowego wymaga formy pisemnej pod rygorem nieważności (art. 53 ustawy o prawie autorskim). Zalecenie: wpisz wprost klauzulę przeniesienia praw z wymienienie pól eksploatacji (art. 74 ust. 4 ustawy o prawie autorskim).

Błąd 3 — brak przekazania kodu w repozytorium zamawiającego. Jeżeli kod jest przechowywany tylko w repozytorium wykonawcy, po zakończeniu umowy zamawiający może utracić dostęp do kodu. Zalecenie: wpisz obowiązek przekazania kodu w repozytorium Git należącym do zamawiającego.

Błąd 4 — brak umowy powierzenia RODO. Gdy aplikacja przetwarza dane osobowe użytkowników i wykonawca ma dostęp do bazy danych testowych lub produkcyjnych, brak umowy powierzenia narusza art. 28 RODO. Zalecenie: zawrzyj odrębną umowę powierzenia przetwarzania danych osobowych.

Błąd 5 — kara umowna za opóźnienie w zapłacie. Kary umownej nie stosuje się za zobowiązania pieniężne (art. 483 KC). Na opóźnienie w zapłacie przysługują odsetki (art. 481 KC). Zalecenie: zastrzegaj kary wyłącznie za zobowiązania niepieniężne (opóźnienie w dostarczeniu etapu, naruszenie poufności).

Błąd 6 — brak wykazu komponentów open source. Pominięcie obowiązku dokumentowania użytych bibliotek open source naraża zamawiającego na nieznane zobowiązania licencyjne (np. GPL copyleft). Zalecenie: wpisz obowiązek dostarczenia listy komponentów open source z ich licencjami.