Blog - Syntanea

Custom software development contract checklist: po co robić tę listę przed podpisem

Umowa na custom software development nie jest formalnością dopinaną po decyzjach. To właśnie w niej lądują decyzje o zakresie, własności kodu, kryteriach odbioru, wsparciu, bezpieczeństwie, płatnościach i wyjściu z projektu.

Większość sporów w projektach software nie zaczyna się od złej woli. Zaczyna się od tego, że dwie rozsądne osoby inaczej rozumieją to samo zdanie. "Moduł użytkowników w zakresie" może oznaczać login i reset hasła. Może też oznaczać SSO, role, logi audytowe, akceptację kont i panel administratora. To są zupełnie inne projekty.

Potraktuj tę listę jako praktyczne sprawdzenie przed podpisem. To nie jest porada prawna. To lista dla founderów, managerów operacyjnych i firm, które zatrudniają zewnętrzny zespół software w Europie.

Opisz zakres oprogramowania prostym językiem

Zacznij od efektu biznesowego, a potem opisz system tak, żeby osoba spoza projektu rozumiała, co jest w środku. Umowa, która mówi tylko "zbudowanie CRM" albo "platforma AI automation", jest zbyt szeroka.

Dobry opis zakresu odpowiada na kilka pytań:

Kto będzie używać systemu? Wypisz role, nie tylko działy.

Jakie są główne workflow? Na przykład: utworzenie oferty, akceptacja, wysyłka do klienta, zapisanie zgody.

Jakie integracje wchodzą do wersji pierwszej? Nazwij systemy i kierunek przepływu danych.

Jakie urządzenia i przeglądarki muszą być wspierane?

Co jest wyraźnie poza zakresem? To jest równie ważne jak lista rzeczy w zakresie.

Jeśli zakres nadal się zmienia, nie wciskaj projektu od razu w fixed price. Najpierw zrób krótkie discovery. Dwa tygodnie discovery bywają tańsze niż kłótnia o sześciomiesięczny projekt zbudowany na domysłach.

Wpisz deliverables i kryteria odbioru do umowy

Deliverable to nie "aplikacja". Rozbij pracę na rzeczy, które da się obejrzeć i odebrać: klikalny prototyp, specyfikacja API, wydanie na stagingu, próbka migracji danych, panel administratora, raport testów, instrukcja deploymentu.

Każdy deliverable potrzebuje kryteriów odbioru. Niech będą konkretne. "Import faktur działa" jest słabe. "System importuje 1 000 wierszy faktur z dostarczonego szablonu CSV, odrzuca wiersze bez NIP i pokazuje użytkownikowi finansowemu raport błędów" jest lepsze.

Dobre kryteria odbioru zdejmują napięcie. Klient wie, co testować. Vendor wie, co znaczy "gotowe". Demo nie zamienia się w rozmowę o odczuciach.

Ustal własność IP i kodu źródłowego

Przy custom software klient zwykle zakłada, że po zapłacie jest właścicielem kodu. Wpisz to w umowę. Ustal też, co dzieje się z bibliotekami vendora, komponentami open source, assetami graficznymi, skryptami infrastruktury i narzędziami, które zespół miał przed projektem.

Klarowny zapis o IP powinien obejmować:

Kto jest właścicielem nowo napisanego kodu po opłaceniu faktur

Czy vendor może ponownie używać ogólnej wiedzy albo komponentów niezwiązanych konkretnie z klientem

Jakie licencje open source są dopuszczalne

Gdzie repozytorium znajduje się w trakcie prac

Kiedy klient dostaje pełny dostęp do kodu, dokumentacji i danych do deploymentu

Nie czekaj z pytaniem o repozytorium do ostatniej faktury. Najbezpieczniejszy układ jest prosty: projekt żyje w organizacji GitHub albo GitLab kontrolowanej przez klienta, a vendor ma dostęp jako współpracownik.

Powiąż płatności z realnym postępem

Częsty model to 20-40% zaliczki, a potem płatności po milestone'ach. To ma sens, jeśli milestone'y oznaczają widoczny postęp, a nie tylko daty w kalendarzu.

Przykładowe milestone'y:

Zatwierdzone discovery i plan techniczny

Odebrany prototyp

Pierwszy produkcyjny workflow działający na stagingu

Zakończone testy integracji

Wdrożenie produkcyjne

Nie płać 80% zanim zobaczysz działające oprogramowanie. Z drugiej strony nie tnij płatności na tak małe części, że vendor musi co chwilę wystawiać faktury. Cashflow powinien pasować do ryzyka po obu stronach.

Opisz change requesty, zanim się pojawią

Każdy projekt custom software się zmienia. Proces, który w pierwszym tygodniu wyglądał prosto, nagle ma trzy ścieżki akceptacji. API zwraca gorsze dane niż zakładano. Stakeholder przypomina sobie o raporcie dopiero po zobaczeniu prototypu.

Umowa powinna mówić, jak zgłasza się zmiany, jak są estymowane, kto je akceptuje i jak są rozliczane. Bez tego luźna wiadomość na Slacku może później stać się sporem o zakres.

Prosta zasada: opisz zmianę, oszacuj wpływ na koszt i termin, uzyskaj pisemną akceptację, dopiero potem zaczynaj dodatkową pracę. Małe zmiany można zebrać do kolejnego przeglądu milestone'u. Zmiany wpływające na kształt produktu traktuj poważnie.

Uwzględnij bezpieczeństwo, RODO i dane

Jeśli system przetwarza dane klientów, pracowników, faktury, dane medyczne albo informacje handlowe, bezpieczeństwo powinno być w umowie. Dla klientów z UE RODO nie jest opcją. Często obok umowy software potrzebna jest też umowa powierzenia przetwarzania danych.

Minimum do ustalenia:

Do jakich danych vendor ma dostęp podczas developmentu

Czy dane produkcyjne mogą trafiać do środowisk testowych

Jak przechowywane są sekrety, API keys i hasła

Czy potrzebne są logi audytowe

Jak zgłasza się incydenty

Czy security review albo penetration test wchodzą do zakresu

Tu warto też ustalić hosting. Jeśli vendor wdraża aplikację na Twoim koncie cloud, dostęp musi dać się łatwo odebrać. Jeśli vendor hostuje aplikację u siebie, zapytaj, co stanie się przy migracji do innego dostawcy.

Nie pomijaj maintenance i handoveru

Pierwsze wdrożenie nie kończy życia systemu. Przeglądarki się zmieniają, API potrafią się zepsuć, zależności wymagają aktualizacji, a użytkownicy znajdują ostre krawędzie dopiero w realnej pracy.

Przed startem ustal, jak wygląda wsparcie:

Okres gwarancji na błędy znalezione po wydaniu

Czasy reakcji na pilne problemy

Miesięczny budżet maintenance

Odpowiedzialność za monitoring i backupy

Dokumentacja i szkolenie przy przekazaniu

Plan wyjścia, jeśli zmienisz vendora

Dobra umowa sprawia, że wyjście z projektu jest nudne. Powinieneś móc odejść z kodem, dokumentacją, instrukcją deploymentu, dostępami i wiedzą potrzebną do utrzymania systemu.

Czerwone flagi w umowie z software housem

Uważaj, jeśli propozycja albo umowa ma takie problemy:

Vendor nie chce zdefiniować kryteriów odbioru

Umowa mówi, że vendor zawsze zachowuje cały kod

Nie ma procesu change requestów

Prawie cała płatność jest z góry

Wsparcie po wdrożeniu nie istnieje w zapisach

Bezpieczeństwo i przetwarzanie danych są opisane jako "standardowe", ale bez szczegółów

Harmonogram zakłada natychmiastowe odpowiedzi od wszystkich stakeholderów

Żaden z tych punktów nie oznacza automatycznie złego vendora. Oznacza, że trzeba zwolnić i zadać konkretne pytania.

Krótka lista przed podpisaniem

Przed podpisaniem umowy na custom software development sprawdź, czy możesz odpowiedzieć "tak" na te pytania:

Czy potrafimy opisać zakres bez ogólnych etykiet produktowych?

Czy wiemy, co jest w wersji pierwszej, a co poza nią?

Czy deliverables mają kryteria odbioru?

Czy wiadomo, kto jest właścicielem kodu i kiedy dostęp jest przekazywany?

Czy płatności są powiązane z realnym postępem?

Czy istnieje pisemny proces change requestów?

Czy RODO, bezpieczeństwo, hosting i dostęp do danych są opisane?

Czy maintenance albo gwarancja są zdefiniowane?

Czy mamy plan handoveru, jeśli współpraca się zakończy?

Jeśli gdzieś odpowiedź brzmi "nie", popraw to przed podpisem. Ta niezręczna rozmowa jest tańsza teraz niż po wydaniu budżetu.

Gdzie pasuje Syntanea

W Syntanea budujemy custom software, automatyzacje AI i narzędzia wewnętrzne dla firm, które chcą praktycznych systemów, nie prezentacji o transformacji. Jesteśmy z Wrocławia i pracujemy z europejskimi klientami, którzy cenią jasny zakres, bezpośrednią komunikację i kod dający się utrzymać.

Jeśli projekt nadal nabiera kształtu, zacznij od poradnika o software development discovery phase. Jeśli porównujesz budżety, przeczytaj custom software development cost w Europie. Jeśli chcesz zamienić luźny pomysł w zakres gotowy do umowy, napisz do nas.

Najczęstsze pytania

Co powinna zawierać umowa na custom software development?

Dobra umowa opisuje zakres, deliverables, kryteria odbioru, płatności, własność IP, change requesty, bezpieczeństwo, dane, maintenance i handover. Dokładny język prawny zależy od jurysdykcji, ale tych punktów biznesowych nie powinno brakować.

Kto jest właścicielem kodu źródłowego w custom software?

Zwykle klient jest właścicielem nowo napisanego kodu po opłaceniu ustalonych faktur. Umowa powinna jednak oddzielić kod specyficzny dla projektu od wcześniejszych bibliotek vendora, komponentów open source i ogólnego know-how.

Fixed price czy time and materials przy projekcie software?

Fixed price działa, gdy zakres jest stabilny, a kryteria odbioru jasne. Time and materials pasuje do produktów, które wymagają iteracji. Wiele projektów używa modelu mieszanego: stałe discovery albo milestone'y, a zmiany rozliczane transparentnie godzinowo.

Jak powinny działać change requesty w projekcie software?

Najbezpieczniej jest wymagać pisemnej akceptacji przed dodatkową pracą. Vendor opisuje zmianę, estymuje wpływ na koszt i termin, a decyzję zatwierdza konkretna osoba po stronie klienta.

Czy potrzebuję prawnika do umowy software development?

Przy poważnym systemie biznesowym tak. Ta lista pomaga wyłapać praktyczne ryzyka projektowe, ale prawnik powinien sprawdzić odpowiedzialność, IP, przetwarzanie danych, jurysdykcję i warunki rozwiązania umowy.

Powiązane artykuły

Software development discovery phase - doprecyzuj zakres, zanim umowa stanie się zgadywanką

Custom software development cost w Europie - widełki budżetowe i modele wyceny przy zewnętrznym zespole

Jak wybrać partnera do tworzenia aplikacji na zamówienie w Europie - co sprawdzić przed podpisaniem umowy z vendorem

Custom software development contract checklist przed podpisaniem umowy