Umowa na aplikację mobilną a spór o odbiór: jak uniknąć patowej sytuacji z software house'em

Aplikacja jest gotowa zdaniem wykonawcy, ale zamawiający uważa inaczej i wstrzymuje płatność końcową. Taki spór potrafi ciągnąć się miesiącami, zabijając relacje biznesowe i generując nieproporcjonalnie wysokie koszty prawne. Bez precyzyjnych kryteriów odbioru w umowie taka sytuacja to raczej norma niż wyjątek w branży IT. W niniejszym artykule omówię, skąd się biorą te konflikty, jakie ramy prawne je regulują i jak je skutecznie zapobiegać na etapie podpisywania umowy.

Spór o „gotowość produktu" — najczęstszy punkt zapalny

Spór o to, czym jest „gotowy produkt", to zdecydowanie najczęstszy punkt zapalny w umowach wdrożeniowych. Problem tkwi w tym, że pojęcie „gotowości" aplikacji jest niezwykle subiektywne.

Z perspektywy programisty aplikacja jest gotowa, gdy:

Kod kompiluje się bez błędów,
Funkcjonalności opisane w specyfikacji technicznej są zaimplementowane,
Podstawowe testy jednostkowe przechodzą,
Aplikacja działa na urządzeniach testowych.

Z perspektywy zamawiającego aplikacja jest gotowa, gdy:

Działa na wszystkich urządzeniach, na których będą ją uruchamiać użytkownicy,
Interface jest intuicyjny i zgodny z jego wyobrażeniem (które może być bogatsze niż to, co faktycznie zamówił),
Prędkość działania jest zadowalająca,
Nie ma żadnych „dziwnych" zachowań ani błędów, nawet tych, których nigdy nie przewidział.

Te dwa obrazy rzadko się pokrywają. Problem pogłębia się, gdy w umowie brakuje precyzyjnej specyfikacji funkcjonalnej — obie strony mają prawo inaczej rozumieć, co miało powstać.

Kategoria prawna umowy — art. 627 KC (umowa o dzieło) vs art. 750 KC (umowa o świadczenie usług)

W zależności od charakteru projektu, umowa na aplikację mobilną kwalifikuje się jako jeden z dwóch typów umów, co ma ogromne znaczenie dla rozdzielenia ryzyka między stronami.

Umowa o dzieło (art. 627 KC)

Umowa o dzieło to umowa, w której zamawiający płaci za konkretny, wymierny efekt. Aplikacja mobilna do zarządzania zamówieniami to dzieło — ma być dostarczone w określonym stanie gotowości.

Kluczowe konsekwencje umowy o dzieło:

Bezwzględna wada dzieła: Jeśli aplikacja nie spełnia uzgodnionego zakresu, zamawiający może żądać poprawy lub rozwiązania umowy i zwrotu wynagrodzenia. Wykonawca odpowiada za wady dzieła niezależnie od tego, czy działał starannie — odpowiedzialność jest obiektywna.
Prawo do odbioru: Zamawiający ma prawo kontrolować, czy dzieło spełnia umowę, i akceptować lub odrzucać je. Protokół odbioru jest kluczowym dokumentem.
Przejście ryzyka: Do momentu odbioru ryzyko (np. zniszczenie aplikacji, opóźnienie na skutek siły wyższej) spoczywa na wykonawcy.
Gwarancja wykonania: Wykonawca gwarantuje, że dzieło zostanie wykonane zgodnie z umową — to on musi wykazać, że spełnił zobowiązania.

Umowa o dzieło chroni więc zamawiającego bardziej niż umowa o usługi. Jednak wykonawcom (software house'om) trudniej jest pracować w ramach umowy o dzieło, bo odpowiedzialność jest surowsza.

Umowa o świadczenie usług (art. 750 KC)

W umowie o usługi zamawiający płaci za wysiłek, a nie za konkretny efekt. Przykład: „Świadczymy usługę programistycznych prac nad aplikacją za X godzin na miesiąc".

Kluczowe konsekwencje umowy o usługi:

Wykonawca odpowiada za staranność, nie za efekt: Software house musi działać z odpowiednią starannością, ale nie gwarantuje, że aplikacja będzie wolna od błędów czy że będzie spełniać wszystkie życzenia zamawiającego.
Brak bezwzględnego obowiązku poprawy: Jeśli coś nie działa, wykonawca jest zobowiązany do usunięcia błędu (o ile to błąd, nie nowa funkcja), ale nie musi na własny koszt dodawać nowych funkcjonalności.
Ryzyko spoczywa na zamawiającym: Jeśli projekt się nie uda, zamawiający i tak musi zapłacić za świadczony wysiłek.

Umowa o usługi jest bardziej korzystna dla wykonawcy (software house'u), ale pozostawia zamawiającego w gorszej pozycji, jeśli projekt pójdzie źle.

Praktyka: Większość umów wdrożeniowych zawiera elementy obu kategorii — hybrid. Na przykład: umowa o dzieło dla pewnych, jasno określonych modułów, ale umowa o usługi dla testowania i optymalizacji. Taka mieszanina wymaga jednak precyzyjnego wyodrębnienia, co należy do którego typu.

Gdzie biorą się spory o odbiór — główne przyczyny

1. Brak szczegółowej specyfikacji funkcjonalnej

Jeśli zakres aplikacji opisano ogólnikowo, na przykład jako „aplikacja do zarządzania zamówieniami z panelem klienta", obie strony mają prawo inaczej rozumieć, co dokładnie miało powstać. Zamawiający może interpretować to jako: „system z wbudowanym reportingiem, integracją z systemem księgowym, mobilną wersją i powiadomieniami email", a wykonawca jako: „baza danych z formularzami CRUD".

Brak szczegółowej specyfikacji to potencjalna mina czasowa, odkrywana zawsze w połowie projektu, gdy uwidaczniają się pierwsze nieporozumienia.

2. Mylenie błędów z nowymi funkcjonalności

To jest drugi częsty konflikt: różnica między błędem (wadą uniemożliwiającą prawidłowe działanie uzgodnionych funkcji) a życzeniem dotyczącym nowych funkcjonalności, które nie były częścią pierwotnego zakresu.

Przykład:

Błąd: Formularz do logowania nie akceptuje hasła z polskimi znakami. To wada — funkcja zalogowania powinna działać dla wszystkich użytkowników.
Nowa funkcjonalność: Zamawiający chce dodatkowego raportu analitycznego, którego nie było w specyfikacji. To nowe życzenie, a nie błąd.

Prawnie to fundamentalna różnica, bo błędy obciążają wykonawcę (i uzasadniają wstrzymanie płatności końcowej), a dodatkowe funkcje stanowią odrębne zlecenie podlegające osobnej wycenie.

W praktyce, bez jasnych kryteriów w umowie, każda strona wyobraża sobie inaczej, co jest błędem, a co życzeniem.

3. Różne platformy i urządzenia

Aplikacja mobilna musi działać na iOS i Android. Zamawiający mógł zamawiać aplikację „mobilną", ale rozumiał to jako „działa identycznie na telefonie i tablecie na obu systemach operacyjnych". Wykonawca zamawiającego rozumiał to jako „jedna uniwersalna wersja na Android". Odkrycie takie przychodzi zwykle podczas testów przy zaawansowanym już projekcie.

Co powinna zawierać umowa, żeby ograniczyć ryzyko sporu

Dobrze skonstruowana umowa wdrożeniowa powinna zawierać kilka kluczowych elementów, których celowo omówię szczegółowo.

1. Specyfikacja funkcjonalna — serce umowy

Specyfikacja powinna być dołączona jako załącznik do umowy i zawierać:

Listę konkretnych funkcji: Nie „system do zarządzania zamówieniami", ale „formularz do dodawania nowego zamówienia, zawierający pola: numer zamówienia, data, klient, lista produktów z cenami, uwagi, historia zmian". Każda funkcja powinna mieć swoją opisową linię lub kilka linii.
Scenariusze użycia (use cases): Np. „Użytkownik loguje się, przechodzi do sekcji Zamówienia, klikuje Nowe, wpisuje dane, system waliduje pole email, jeśli jest błędne — wyświetla komunikat błędu".
Wygląd interfejsu: Mockupy lub wireframy pokazujące rozmieszczenie elementów, kolory, rozmiary czcionek.
Wymagania techniczne: Które wersje iOS/Android, jaka minimalna prędkość internetu, czy offline mode, czy powinna działać na emulatorach itp.
Wyłączenia: Explicit list tego, co NIE jest objęte — np. „Integracja z systemem SAP nie jest objęta. Backup danych nie jest objęty. Szkolenie użytkowników nie jest objęte".

Specyfikacja powinna być zatwierdzana przez obie strony podpisem PRZED rozpoczęciem projektu. Każda zmiana do specyfikacji powinna wymagać aneksu do umowy.

2. Procedura odbioru — jasne kroki i terminy

Umowa powinna precyzować procedurę odbioru:

Termin na zgłoszenie uwag: Zamawiający ma np. 5 dni roboczych od otrzymania aplikacji do zgłoszenia uwag. Po upływie tego terminu milczenie oznacza akceptację.
Forma zgłoszenia uwag: Muszą być pisemne (email, formularz), z opisem problemu — nie ustne rozmowy przy kawie.
Klasyfikacja uwag: Uwagi dzielą się na krytyczne (blokujące odbiór), poważne (wymagające naprawy przed płaceniem) i drobne (mogą być naprawiane po odbiorze).
Procedura naprawy: Jeśli zgłoszone są uwagi, wykonawca ma np. 10 dni na naprawę. Po naprawie — ponowny okres testów dla zamawiającego.
Protokół odbioru: Po zaakceptowaniu — podpisanie protokołu przez obie strony. To dokument, który powinien być dołączony do faktury.

3. Wyraźny podział na wady istotne i nieistotne

Umowa powinna zdefiniować, co jest wadą, która blokuje odbiór, a co jest wadą, którą można naprawiać „na boku":

Wady istotne (blocking): Aplikacja się nie uruchomia, logowanie nie działa, tracą się dane.
Wady nieistotne (non-blocking): Ikona jest nieco rozmyta, czcionka w jednym miejscu jest o 1 pixel mniejsza, niż powinna, przycisk animuje się zbyt powoli.

Wady istotne uniemożliwiają odbiór. Wady nieistotne mogą być naprawiane w uzgodnionym terminie po podpisaniu protokołu odbioru (np. w ciągu 30 dni).

4. Procedura zmian zakresu

Umowa powinna definiować jasny mechanizm wyceny i akceptacji dodatkowych funkcji zgłoszonych już po rozpoczęciu prac. Na przykład:

Zamawiający zgłasza nową funkcjonalność pisemnie.
Wykonawca oszacowuje koszt i czas implementacji w ciągu 2 dni.
Jeśli zamawiający akceptuje — zawierana zmiana do umowy (aneks) z nową ceną i terminem.
Funkcjonalność nie jest objęta odbiorem pierwotnym — odbierana osobno.

Brak takiej procedury oznacza, że każda zgłoszona przez zamawiającego idea podczas testów będzie przedmiotem negocjacji i sporu.

Jak wygląda patowa sytuacja, gdy brakuje tych postanowień

Scenariusz bez precyzyjnych zapisów w umowie:

Tydzień 1-8: Wykonawca pracuje intensywnie. Zamawiający nie ma dostępu do prac w progress — widzi rezultat dopiero na koniec.
Tydzień 8: Wykonawca zgłasza „gotowość do testów". Zamawiający otrzymuje aplikację i zaczyna testować.
Tydzień 9-10: Zamawiający wysyła listę uwag, gdzie mniej więcej 40% z nich to „nowe" funkcje, które nigdy nie były w specyfikacji (bo specyfikacji prawie nie było), a 30% to subiektywne krytyki designu.
Tydzień 11: Spór: wykonawca mówi „to nowe funkcje, dodatkowe koszty", zamawiający mówi „to podstawowe rzeczy, których się spodziewałem". Żaden z nich nie ma siły persuazji opartej na dokumencie.
Tydzień 12-20: Negocjacje, korespondencja, możliwe mediacje. Zamawiający wstrzymuje płatność końcową. Wykonawca wstrzymuje dalsze prace.
Miesiąc 6-12: Ewentualne postępowanie sądowe z powołaniem biegłego informatyka, który ocenia, czy sporne elementy mieściły się w pierwotnym zakresie. Do kosztów trzeba doliczyć opłatę sądową (co do zasady 5% wartości dochodzonego roszczenia), wynagrodzenie biegłego oraz koszty zastępstwa procesowego — w sporach o średniej wartości łączne koszty obu stron bywają porównywalne z istotną częścią wartości samego kontraktu.

Takie scenariusze są niestety powszechne w branży IT i generują frustrację po obu stronach, a także uszkadzają wzajemne relacje.

Jak wyjść z patowej sytuacji, gdy spór już trwa

Jeśli do sporu już doszło i pracami kieruje już frustracja, ale zanim sprawa trafi do sądu, warto rozważyć niezależny audyt techniczny.

Opcja 1: Audyt techniczny prowadzony przez trzecią stronę

Niezależny specjalista (zewnętrzny inżynier/architekt IT, nie zatrudniony przez żaden z stron) ocenia:

Które ze zgłoszonych uwag są realnymi błędami, które uniemożliwiają prawidłowe działanie aplikacji,
Które to są nowe funkcje, które nie były w pierwotnym zakresie,
Które to są kwestie designu lub preferencji, a nie rzeczywiste wady.

Taka opinia, sporządzona jeszcze przed procesem, często staje się podstawą do ugody, ponieważ obiektywizuje spór, który wcześniej opierał się wyłącznie na wzajemnych oskarżeniach.

Koszt takiego audytu: zwykle kilka tysięcy złotych. To niewiele w porównaniu z kosztami procesu sądowego i bezwartościowymi zasobami poświęconymi na konflikt.

Opcja 2: Mediacja

Mediator (niezaangażowany prawnik) ułatwia rozmowy między stronami, pomagając każdej zrozumieć perspektywę drugiej. W wielu przypadkach spór ma swoje źródło w komunikacyjnym nieporozumieniu — mediacja potrafi je rozproszyć.

Opcja 3: Ugoda częściowa

Czasem najlepszym wyjściem jest: zamawiający płaci 80% kwoty za moduły bezspornie wykonane, wykonawca poprawia zgłoszone błędy w ciągu 30 dni, dyskusyjne funkcje są zaplanowane osobno w przyszłym projekcie.

Taka ugoda jest szybka, obie strony coś zyskują, a relacja nie jest całkowicie zniszczona.

Praktyczne porady dla zamawiającego (nie-technicznego)

Zaangażuj się w specyfikację od samego początku. Nie bądź biernymi obserwatorem — wlaz w szczegóły tego, co zamawiasz. Rysuj mockupy, opisz codzienne scenariusze użytkowników, pytaj głupie pytania.
Testuj wcześnie i często. Zamiast czekać 2 miesiące na „gotowość", poproś dostęp do aplikacji już po miesiącu, nawet jeśli coś nie działa. Wczesne odkrycie nieporozumienia to oszczędność.
Zaakceptuj, że zmienisz zdanie. Nowe pomysły będą się pojawiać w trakcie testów. OK — ale każda zmiana powinna być formalnie zgłaszana i wyceniana jako dodatkowe zlecenie.
Dokumentuj wszystko na piśmie. Nie polecaj zmian ustnie. Email, formularz w projekcie, komentarz w repozytorium — cokolwiek, byle na piśmie.

Praktyczne porady dla wykonawcy (software house)

Bądź precyzyjny przy specyfikacji. Jeśli coś jest niejasne — nie rób sobie „artystycznej swobody". Pytaj zamawiającego, pisz założenia techniczne, które odsyłasz do akceptacji.
Pokaż postępy regularnie. Cotygodniowe, 30-minutowe demo (nawet niekompletne) prevenuje duże rozczarowania na koniec.
Pisz testy automatyczne (unit tests, integration tests). One dokumentują, co aplikacja powinna robić — to rodzaj „żywej specyfikacji".
Uzgadniaj termin testów z zamawiającym z wyprzedzeniem. „Za dwa tygodnie będzie pierwsze demo" — nie „będzie gotowe bez uprzedzenia".

FAQ — najczęstsze pytania

Pytanie: Czy mogę jako zamawiający wstrzymać płatność, jeśli znalazłem drobny błąd?

Prawo pozwala na wstrzymanie płatności za dzieło niespełniające umowy. Ale „drobny błąd" — to kwestia interpretacji. Jeśli w umowie zdefiniowaliśmy, że wady nieistotne nie blokują odbioru, to wstrzymanie jest bezprawne. Jeśli takiej definicji nie ma — masz większą swobodę, ale ryzyko sporu wzrasta.

Pytanie: Ile czasu powinien mieć zamawiający na testy?

Standardem branżowym jest 5-10 dni roboczych. Mniej — zamawiający może poczuć się pośpieszony. Więcej — projekt „wisi" zbyt długo. Liczba powinna być w umowie.

Pytanie: Czy mogę jako wykonawca żądać zapłaty za poprawę błędu znalezionego przez zamawiającego?

Tylko jeśli ten „błąd" to faktycznie nowa funkcjonalność, którą umowa nie obejmowała. Jeśli to rzeczywisty błąd (aplikacja robi coś innego niż się do niej mówi) — no, umowa zobowiązuje Cię do naprawy. Masz prawo żądać zapłaty za nowe funkcje, ale nie za naprawy błędów umownych.

Podsumowanie

Spór o odbiór aplikacji to wysoce nieproduktywna sytuacja, którą można zapobiec za pomocą precyzyjnej umowy i dobrej komunikacji. Klucze to: szczegółowa specyfikacja, jasna procedura odbioru, wyraźny podział na błędy i nowe funkcjonalności, oraz zaangażowanie zamawiającego od samego początku projektu.

Jeśli już do sporu doszło — nie czekaj na sąd. Audyt techniczny, mediacja lub ugoda częściowa to rozwiązania, które są szybsze, tańsze i mniej destrukcyjne dla relacji biznesowych.

Świadom umowa i zaangażowana komunikacja — to dwa fundamenty, na których buduje się udane projekty wdrożeniowe w IT. Bez nich patowa sytuacja czeka na każdym rogu.