Umowa z software housem: 7 klauzul, które chronią zamawiającego

W projektach IT spory dotyczą tego, że strony inaczej rozumiały: zakres, terminy, prawa autorskie, wynagrodzenie i zasady zakończenia współpracy.

Dobra umowa wdrożeniowa z software housem daje obu stronom ramy. Zła umowa albo jej brak - gwarantuje tylko jedno: problemy, gdy projekt się komplikuje.

Artykuł opracowany przez Łukasza Gębczyka - prawnika Lexable, który na co dzień przygotowuje i negocjuje umowy IT dla startupów, firm SaaS i zamawiających usługi programistyczne.

Co wyniesiesz z tego artykułu?

7 kluczowych klauzul w umowie z software housem, które robią największą różnicę, nie tylko operacyjnie, ale i prawnie.
5 czerwonych flag, które najczęściej kończą się sporem lub porzuconym projektem.
Konkretne sformułowania, które możesz sprawdzić w swojej umowie jeszcze dziś.

Dla zabieganych

Umowa z software housem powinna zawierać co najmniej: precyzyjny opis zakresu i metodyki prac, harmonogram z kamieniami milowymi, klauzulę przeniesienia autorskich praw majątkowych, zasady wynagradzania powiązane z odbiorem etapów, klauzulę NDA, procedurę change requestów oraz exit plan z zasadami przekazania kodu i dokumentacji.

Umowa z software housem: czym jest i dlaczego jest niezbędna

Umowa z software housem to kontrakt, na podstawie którego firma programistyczna tworzy oprogramowanie (aplikację, system, platformę) na zlecenie zamawiającego.

W polskim prawie nie istnieje osobny typ „umowy z software housem”. W zależności od treści postanowień, taka umowa może zostać zakwalifikowana jako umowa o dzieło, umowa o świadczenie usług lub umowa mieszana. Kwalifikacja ma realne konsekwencje - choćby w zakresie rękojmi, odstąpienia od umowy czy odpowiedzialności za rezultat.

Większość projektów IT kończy się z przekroczonym budżetem, opóźnieniem lub zakresem innym niż zakładano. Tylko znaczną mniejszość projektów uznaje się za pełny sukces.

Umowa musi być dopasowana do modelu współpracy (fixed price, time & material, Agile), technologii, skali projektu i aktualnych przepisów - w tym zmian wynikających z AI Act, który od sierpnia 2026 r. nakłada obowiązki compliance na systemy AI wysokiego ryzyka.

7 klauzul, które warto mieć w umowie z software housem

1) Zakres prac, metodyka i dokumentacja techniczna

W umowie z software housem zakres to nie ogólny opis „wykonania aplikacji”. To lista funkcjonalności, stosów technologicznych, integracji i założeń architektonicznych. Bez tego zamawiający będzie oczekiwał jednego, a software house dostarczy drugie.

opis funkcjonalności,
wybrana technologia i architektura,
metodyka prac,
wyłączenia: czego software house nie robi,
załącznik: specyfikacja techniczna, wireframe, backlog lub brief projektu.

2) Harmonogram, kamienie milowe i procedura odbioru

Projekt bez harmonogramu to projekt bez punktów kontrolnych. Zamawiający nie wie, czy jest w 30% realizacji, czy w 80%.

podział na etapy (milestones) z terminami lub ramami czasowymi,
definicja „odbioru etapu”: kto testuje, w jakim czasie, jakie kryteria akceptacji,
procedura zgłaszania uwag i poprawek,
konsekwencje opóźnień: co się dzieje, gdy software house nie dowozi na czas,
klauzula force majeure: katalog zdarzeń automatycznie wydłużających terminy.

3) Prawa autorskie i IP (przeniesienie vs. licencja)

To jest klauzula, która najczęściej jest źle napisana - lub której nie ma wcale.

Bez skutecznego przeniesienia praw, zamawiający nie jest właścicielem oprogramowania, za które zapłacił. Nie może go modyfikować, sublicencjonować ani przekazać innemu wykonawcy.

przeniesienie autorskich praw majątkowych na wszystkich polach eksploatacji,
moment przeniesienia praw,
zobowiązanie SH, że posiada prawa do przenoszenia,
regulacja open-source: jakie komponenty są używane i na jakich licencjach,
klauzula indemnity: SH odpowiada, jeśli kod narusza prawa osób trzecich.

Forma pisemna jest obowiązkowa. Przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności.

4) Wynagrodzenie, rozliczenia i płatności

Spory o pieniądze są najczęstszą przyczyną konfliktów w projektach IT.

model rozliczeń: fixed price, time & material, retainer - z opisem mechanizmu,
stawki i co wchodzi w ich skład,
harmonogram płatności powiązany z kamieniami milowymi,
zasady rozliczania prac dodatkowych,
konsekwencje opóźnienia płatności: odsetki + prawo do wstrzymania prac.

5) Poufność i NDA

Podczas realizacji projektu IT obie strony wymieniają się informacjami o wartości biznesowej: koncepcja produktu, baza klientów, architektura, know-how techniczny.

definicja informacji poufnych (kod, dokumentacja, dane klientów, strategia),
czas obowiązywania,
zakaz korzystania z informacji poufnych do celów własnych,
zobowiązanie SH do zapewnienia poufności ze strony podwykonawców,
kara umowna za naruszenie.

Więcej: NDA dla IT i startupów: 7 klauzul, które realnie chronią kod, know-how i klientów.

6) Zespół projektowy, komunikacja i zakaz przejmowania pracowników

Software house sprzedaje kompetencje ludzi. Jeśli w trakcie projektu kluczowy programista odejdzie, a zastąpi go junior - efekt może być katastrofalny.

wskazanie kluczowych osób w zespole,
obowiązek informowania zamawiającego o zmianach w składzie zespołu,
zasady komunikacji: narzędzia, częstotliwość spotkań, osoba kontaktowa,
zakaz przejmowania pracowników (non-solicitation) - chroni obie strony.

7) Rozwiązanie umowy, exit plan i przekazanie kodu

W projekcie IT wyjście jest równie ważne jak wejście. Gdy współpraca się nie układa, musisz wiedzieć, jak odejść bez utraty tego, za co zapłaciłeś.

tryby zakończenia: wypowiedzenie, rozwiązanie z ważnych przyczyn, natychmiastowe,
zasady rozliczenia przy przedterminowym zakończeniu,
przekazanie kodu źródłowego, dokumentacji, środowisk, kluczy,
termin na przekazanie,
prawo do wykonania zastępczego.

Bez exit planu zamawiający zostaje z niedokończonym projektem, bez kodu, bez dokumentacji i bez możliwości kontynuacji. To jest definicja vendor lock-in. Warto sprawdzić nasz inny wpis: Umowa B2B z programistą: 7 klauzul, które chronią IP.

5 czerwonych flag: rozpoznasz je w 30 sekund

Brak klauzuli IP albo IP „w domyśle” - bez wyraźnego przeniesienia praw majątkowych w formie pisemnej zamawiający nie ma praw do kodu.
Brak harmonogramu i procedury odbioru - software house „będzie informował o postępach” zamiast zdawać konkretne etapy do formalnego odbioru.
Wynagrodzenie T&M bez limitu ani mechanizmu kontroli - zamawiający płaci za godziny, ale nie ma narzędzi do weryfikacji.
Brak exit planu - nie wiadomo, jak zamawiający odzyska dokumentację projektową i w jakim terminie po zakończeniu umowy.
Software house nie ma klauzul IP z własnymi programistami - prawa autorskie mogą nie „przejść” przez łańcuch, jeśli SH nie nabył ich od swoich kontraktorów B2B.

FAQ

Czy umowa z software housem musi być na piśmie?

Nie ma obowiązku pisemności dla całej umowy. Ale jeśli zawiera klauzulę przeniesienia autorskich praw majątkowych, a powinna, to ta część musi mieć formę pisemną pod rygorem nieważności. W praktyce: cała umowa na piśmie.

Czy to umowa o dzieło czy o świadczenie usług?

Zależy od treści. Konkretny rezultat (aplikacja o określonych cechach) - bliżej do dzieła. Dostarczanie ludzi i czasu (T&M, body leasing) - bliżej do usług. Kwalifikacja ma znaczenie m.in. dla rękojmi i odpowiedzialności.

Jak zabezpieczyć się, gdy software house porzuca projekt?

Klauzula wykonania zastępczego (art. 480 Kodeksu cywilnego), rozwiązanie z ważnych przyczyn, obowiązek bieżącego przekazywania kodu do repozytorium zamawiającego, harmonogram z płatnościami powiązanymi z odbiorem.

Czy Software House może używać kodu z mojego projektu w innych projektach?

Nie - jeśli umowa skutecznie przenosi prawa majątkowe. Wyjątek: komponenty pre-existing IP, które SH stworzył wcześniej i wykorzystuje na zasadzie licencji. Umowa powinna wyraźnie oddzielać IP zamawiającego od pre-existing IP.

Co z AI Act?

Jeśli system zawiera komponent AI - od 2 sierpnia 2026 r. mogą obowiązywać wymogi AI Act dotyczące systemów wysokiego ryzyka. Umowa powinna przypisywać odpowiedzialność za compliance.

Ile kosztuje przygotowanie umowy przez prawnika?

W Lexable - stała, z góry określona cena. Nie płacisz za godziny. Dokument dopasowany do modelu współpracy, gotowy ~ 12h.

Czy mogę użyć wzoru z internetu?

Możesz, ale ryzykujesz. Darmowe wzory nie uwzględniają Twojego modelu rozliczeń, metodyki, specyfiki IP ani aktualnych przepisów. Przy projekcie za 100 000 PLN oszczędność 1090 PLN na prawnika to dramatyczna proporcja ryzyka.

Chcesz umowę z software housem dopasowaną do Twojego projektu?

Rozpocznij teraz i wybierz jedną z opcji:

zamów przygotowanie umowy z software housem w Lexable (pod Twój model współpracy, technologię i skalę projektu),
prześlij obecną umowę do przeglądu - wskażemy czerwone flagi i gotowe poprawki.

Wolisz mailowo? Napisz: contact@lexable.pl