Masz pomysł na aplikację. Po kilku rozmowach wybrałeś software house, znasz szacunkowy budżet i termin. Na biurku leży już umowa na stworzenie aplikacji mobilnej, a wykonawca prosi o podpis „najlepiej w tym tygodniu, żeby zespół mógł zacząć od poniedziałku”.
Na tym etapie łatwo potraktować umowę jak formalność. Warunki biznesowe zostały już omówione, relacja jest dobra, a wszyscy chcą zacząć pracę. Umowa na stworzenie aplikacji mobilnej nie jest jednak potrzebna na czas, gdy projekt idzie zgodnie z planem. Wtedy mało kto do niej zagląda. Jej wartość sprawdza się w momencie, gdy termin się przesuwa, budżet rośnie, aplikacja działa inaczej, niż zakładałeś, albo współpraca zaczyna się psuć.
Dobra umowa powinna więc odpowiadać na dwa pytania: jak ma przebiegać projekt oraz co się stanie, jeśli nie przebiegnie zgodnie z pierwotnym planem. Poniżej omawiam siedem obszarów, które warto przeanalizować przed podpisaniem umowy z software house’em. Nie wyczerpuję tu każdego tematu, bo część z nich wymaga osobnego omówienia. Celem jest pokazanie, gdzie leży ryzyko i jakie pytania zadać, zanim złożysz podpis.
Umowa na stworzenie aplikacji mobilnej – jaki to rodzaj umowy?
W potocznym języku mówi się o „umowie na aplikację”, „umowie IT” czy „umowie wdrożeniowej”. Przepisy nie znają jednak jednej umowy na stworzenie oprogramowania. W zależności od treści i modelu współpracy taka umowa może zostać zakwalifikowana na przykład jako umowa o dzieło, umowa o świadczenie usług albo umowa mieszana, która łączy elementy kilku typów.
Nie jest to akademicki spór. Od kwalifikacji mogą zależeć zasady odpowiedzialności wykonawcy, możliwość odstąpienia od umowy czy skutki opóźnienia. Umowa, w której rozliczasz się za przepracowane godziny zespołu, będzie oceniana inaczej niż umowa na wykonanie konkretnej aplikacji za z góry ustaloną cenę.
Wniosek praktyczny: kluczowych kwestii nie warto zostawiać przepisom ogólnym. Im więcej zostanie uregulowane wprost w umowie, tym mniej zależy od tego, jak spór zostałby później oceniony.
1. Zakres prac i specyfikacja – co dokładnie kupujesz?
To obszar, od którego zależy prawie wszystko inne. Jeśli strony nie wiedzą, co dokładnie ma powstać, trudno ocenić, czy aplikacja została wykonana prawidłowo, czy termin został dotrzymany i czy dodatkowa praca wymaga dopłaty.
Częsty problem to umowa odsyłająca do ogólnego opisu w stylu „aplikacja mobilna do rezerwacji wizyt na iOS i Androida, zgodnie z ustaleniami stron”. Dla zamawiającego to zdanie oznacza pełny produkt z panelem administracyjnym, płatnościami i powiadomieniami. Dla wykonawcy może oznaczać wersję podstawową, a wszystko ponad nią to dodatkowy zakres.
Pytanie, które warto sobie zadać: czy osoba trzecia, która przeczyta umowę i załączniki, będzie w stanie ustalić, co dokładnie miało zostać dostarczone?
W dobrze przygotowanej specyfikacji zwykle opisuje się między innymi:
- funkcjonalności aplikacji i role użytkowników,
- platformy i minimalne wersje systemów operacyjnych,
- elementy poza samą aplikacją, np. backend, panel administracyjny, integracje z systemami zewnętrznymi,
- wymagania niefunkcjonalne, np. wydajność, bezpieczeństwo, dostępność,
- to, czego zakres prac nie obejmuje.
Ostatni punkt bywa niedoceniany. Jasne wyłączenie (np. „projekt nie obejmuje przygotowania treści, publikacji w sklepach ani utrzymania po wdrożeniu”) zapobiega sporom lepiej niż długi opis funkcji.
Nie w każdym projekcie da się na starcie przygotować pełną specyfikację. W projektach zwinnych zakres doprecyzowuje się w trakcie. To nie jest błąd, ale wtedy umowa powinna opisywać, jak ten zakres będzie ustalany i zatwierdzany.
2. Harmonogram – kto od kogo zależy?
Harmonogram w umowie często ogranicza się do daty końcowej. Tymczasem przy tworzeniu aplikacji termin wykonawcy prawie zawsze zależy także od zamawiającego: od dostarczenia materiałów, dostępu do systemów, akceptacji projektów graficznych czy udzielenia odpowiedzi na pytania zespołu.
Jeśli umowa tego nie opisuje, w sporze o opóźnienie obie strony będą miały swoją wersję wydarzeń. Wykonawca wskaże, że czekał dwa tygodnie na akceptację makiet, a zamawiający, że wykonawca nie zgłaszał żadnego problemu.
Pytanie do zadania: czy z harmonogramu wynika, jakie są etapy projektu, jakie obowiązki ma każda ze stron i co się dzieje z terminem, gdy któraś z nich się spóźni?
Przy aplikacjach mobilnych jest jeszcze jeden szczegół. Publikacja w App Store i Google Play wymaga przejścia weryfikacji przez Apple i Google, na którą wykonawca nie ma pełnego wpływu. Warto więc odróżnić w umowie termin przekazania aplikacji gotowej do publikacji od faktycznej publikacji w sklepie.
3. Wynagrodzenie – za co i kiedy płacisz?
W projektach aplikacji mobilnych najczęściej spotyka się dwa modele:
- wynagrodzenie ryczałtowe (fixed price) – ustalona cena za określony zakres; daje przewidywalność budżetu, ale wymaga dobrze opisanej specyfikacji, a każda zmiana zakresu zwykle oznacza renegocjację,
- rozliczenie godzinowe (time & material) – płacisz za faktycznie przepracowany czas; model jest elastyczny, ale budżet pozostaje otwarty.
Żaden z nich nie jest z góry lepszy. Ryzyko pojawia się wtedy, gdy model rozliczenia nie pasuje do sposobu prowadzenia projektu. Przykład: sztywna cena przy zakresie, który dopiero się kształtuje, zwykle kończy się sporem o to, co było w cenie, a co nie.
Pytania, które warto zadać przed podpisaniem umowy:
- Czy płatności są powiązane z postępem prac (np. z odbiorem kolejnych etapów), czy z upływem czasu?
- Czy przy rozliczeniu godzinowym masz wgląd w raporty i jakiś mechanizm kontroli budżetu, np. obowiązek wcześniejszego uprzedzenia o przekroczeniu określonej kwoty?
- Czy wynagrodzenie obejmuje przeniesienie praw autorskich, czy wykonawca może oczekiwać za to dodatkowej zapłaty?
Ostatnie pytanie wraca w sekcji o prawach autorskich. Jeżeli strony zakładają przeniesienie praw, umowa powinna jasno określać, czy wynagrodzenie obejmuje również to przeniesienie.
4. Odbiór aplikacji – kiedy projekt uznaje się za wykonany?
Odbiór to moment, w którym zwykle dzieją się rzeczy ważne dla obu stron: powstaje obowiązek zapłaty (całości lub kolejnej transzy), często przechodzą prawa autorskie, a czasem zaczyna biec okres gwarancji. Dlatego procedura odbioru należy do najczęściej negocjowanych postanowień umowy z software house’em.
Po stronie zamawiającego ryzyko polega zwykle na tym, że odbiór jest zbyt szybki lub zbyt ogólny. Umowa może na przykład przewidywać, że jeśli zamawiający nie zgłosi zastrzeżeń w określonym terminie od formalnego zgłoszenia wykonawcy, etap uznaje się za odebrany. Taki mechanizm może być skutecznie przewidziany w umowie. Działa jednak tylko wtedy, gdy wykonawca rzeczywiście dokona zgłoszenia w sposób przewidziany w umowie. Jeśli jednak termin na testy jest zbyt krótki w stosunku do złożoności aplikacji, zamawiający może formalnie odebrać produkt, którego w praktyce nie zdążył sprawdzić.
Po stronie wykonawcy ryzyko jest odwrotne: odbiór, który nigdy się nie kończy, bo przy każdej rundzie pojawiają się nowe uwagi.
Dobra procedura odbioru odpowiada w szczególności na pytania:
- co jest przedmiotem odbioru i według jakich kryteriów będzie oceniany,
- na jakich urządzeniach i wersjach systemów aplikacja ma być testowana,
- ile czasu ma zamawiający na testy i w jakiej formie zgłasza zastrzeżenia,
- czy drobne błędy blokują odbiór, czy tylko zobowiązują wykonawcę do ich usunięcia.
Pytanie kontrolne: czy wiesz, jakie konkretne działanie (lub zaniechanie) z Twojej strony spowoduje, że aplikacja zostanie uznana za odebraną?
5. Prawa autorskie i kod źródłowy – czy aplikacja będzie naprawdę Twoja?
To obszar, w którym najczęściej spotykam się z błędnym założeniem: „płacę za aplikację, więc jest moja”. Zapłata za wykonanie aplikacji nie oznacza automatycznie nabycia praw autorskich do niej.
Program komputerowy jest w polskim prawie chroniony jak utwór literacki. Autorskie prawa majątkowe przysługują pierwotnie twórcy (lub, w przypadku programu stworzonego przez pracownika w ramach obowiązków ze stosunku pracy, pracodawcy). Aby prawa przeszły na zamawiającego, potrzebna jest umowa, która to przewiduje.
Przeniesienie praw czy licencja?
Umowa może przewidywać przeniesienie autorskich praw majątkowych albo udzielenie licencji. To dwie różne sytuacje. Przy przeniesieniu prawa przechodzą na Ciebie. Przy licencji zostają przy wykonawcy, a Ty otrzymujesz zgodę na korzystanie z aplikacji w określonym zakresie.
Kilka zasad wynikających z przepisów ma tu bezpośrednie znaczenie praktyczne:
- umowa o przeniesienie autorskich praw majątkowych wymaga formy pisemnej pod rygorem nieważności. Akceptacja oferty w mailu nie spełnia tego wymogu. Nie spełnia go też podpis w narzędziu do e-podpisu, które nie zapewnia kwalifikowanego podpisu elektronicznego,
- umowa obejmuje tylko te pola eksploatacji, które zostały w niej wyraźnie wymienione,
- jeśli umowa nie przewiduje wyraźnie przeniesienia praw, uznaje się, że udzielono licencji. Licencja bez określenia czasu i terytorium jest co do zasady ograniczona czasowo i terytorialnie.
Więcej o tym, jak uregulować prawa autorskie do aplikacji mobilnej i dostęp do kodu, piszę w osobnym artykule. Na tym etapie wystarczy sprawdzić, czy umowa w ogóle mówi o przeniesieniu praw, czy robi to w formie, która będzie skuteczna, i od kiedy to przeniesienie następuje. Wiele umów przewiduje przejście praw dopiero z chwilą zapłaty. Z perspektywy wykonawcy to zrozumiałe, ale zamawiający powinien wiedzieć, jakie prawa ma do części aplikacji, za które już zapłacił, jeśli współpraca zakończy się w połowie projektu.
Prawa do kodu to nie to samo co dostęp do kodu
Nabycie praw autorskich nie oznacza automatycznie, że otrzymasz kod źródłowy. Przeniesienie praw i wydanie egzemplarza utworu to w prawie autorskim dwie odrębne kwestie. Można więc mieć pełnię praw do aplikacji i jednocześnie nie mieć dostępu do repozytorium, dokumentacji technicznej ani środowisk, bez których nowy wykonawca nie będzie w stanie jej rozwijać.
Dlatego umowa powinna określać, co, kiedy i w jakiej formie jest Ci przekazywane: kod źródłowy (najlepiej przez bieżący dostęp do repozytorium, a nie jednorazowe przekazanie na koniec), dokumentacja, dane dostępowe.
Praktyczna uwaga poza samą umową: konta deweloperskie w Apple i Google, konta w usługach chmurowych, domeny i klucze do podpisywania aplikacji powinny być zakładane na Ciebie jako zamawiającego, a nie na wykonawcę. Odzyskanie ich po zakończeniu współpracy bywa trudniejsze niż odzyskanie kodu.
Skąd wykonawca ma prawa, które przenosi?
Software house może przenieść na Ciebie tylko te prawa, które sam ma. Jeśli aplikację tworzą jego pracownicy zatrudnieni na umowę o pracę, prawa do programu co do zasady przysługują mu z mocy prawa. Jeśli jednak pracują na nią programiści współpracujący w modelu B2B lub podwykonawcy, software house musi uzyskać od nich prawa w drodze umowy. Warto, aby wykonawca złożył w umowie zapewnienie, że prawa te posiada, i odpowiadał wobec Ciebie, jeśli okaże się inaczej.
Osobna kwestia to gotowe komponenty: biblioteki open source czy własne narzędzia wykonawcy, wykorzystywane w wielu projektach. Do nich zwykle nie otrzymasz przeniesienia praw, lecz licencję. To normalne, ale warto wiedzieć, jakie komponenty trafią do Twojej aplikacji i na jakich zasadach możesz z nich korzystać.
6. Zmiana zakresu – co się stanie, gdy zmienisz zdanie?
W prawie każdym projekcie pojawiają się zmiany. Po pierwszych testach z użytkownikami okazuje się, że jakaś funkcja jest zbędna, a innej brakuje. To naturalne i nie świadczy o złym planowaniu.
Problem pojawia się wtedy, gdy umowa nie mówi, jak takie zmiany wprowadzać. Zmiany ustalane na spotkaniu, w wątku na Slacku czy w komentarzu w narzędziu do zarządzania zadaniami łatwo potem podważyć. W efekcie na koniec projektu strony spierają się, czy dana funkcja była w pierwotnym zakresie i czy należy się za nią dodatkowe wynagrodzenie.
Pytanie do zadania: jeśli w trakcie projektu poprosisz o zmianę, to czy z umowy wynika, kto wyceni jej koszt, kto ją zatwierdzi i jak wpłynie ona na termin?
Mechanizm ten w branży nazywa się zwykle procedurą change request. Jego konstrukcja zależy od projektu i modelu rozliczenia. Przy wynagrodzeniu ryczałtowym jest szczególnie ważny, bo każda zmiana wpływa na ustaloną cenę. Szczegóły to temat na osobny tekst. Przed podpisaniem umowy wystarczy upewnić się, że taka procedura w ogóle istnieje i wymaga udokumentowanej akceptacji obu stron.
7. Zakończenie współpracy – plan na wypadek, gdyby coś poszło nie tak
Na etapie podpisywania umowy nikt nie planuje rozstania. Mimo to warto zadać sobie pytanie, które na tym etapie wydaje się najmniej przyjemne: co się stanie, jeśli w połowie projektu będziesz chciał lub musiał zmienić wykonawcę?
Jeśli umowa tego nie reguluje, zakończenie współpracy może być kosztowne i nieprzewidywalne. Dobrze to widać na przykładzie przepisów o umowie o dzieło. Jeśli umowa zostanie tak zakwalifikowana, a strony nie uregulowały tego inaczej, zamawiający może co do zasady odstąpić od niej przed ukończeniem dzieła. Musi jednak zapłacić umówione wynagrodzenie, pomniejszone o to, co wykonawca zaoszczędził, nie kończąc pracy. Dla wielu founderów jest to spore zaskoczenie.
Niezależnie od kwalifikacji umowy warto sprawdzić, czy wynika z niej:
- w jakich sytuacjach każda ze stron może zakończyć współpracę i z jakim wyprzedzeniem,
- ile zapłacisz za prace wykonane do dnia zakończenia umowy,
- co dostaniesz przy rozstaniu: kod, dokumentację, dostępy, prawa do dotychczasowych prac,
- czy wykonawca ma obowiązek współpracować przy przekazaniu projektu nowemu zespołowi.
Szczegółowe zasady rozwiązania i odstąpienia od umowy omówię w osobnym artykule. Najważniejsze jest to, żeby umowa w ogóle zawierała taki „plan wyjścia”, a nie zakładała wyłącznie scenariusz, w którym wszystko idzie zgodnie z planem.
Umowa na stworzenie aplikacji mobilnej: 7 pytań przed podpisaniem
Jeśli masz przed sobą projekt umowy od software house’u, możesz przejrzeć go przez pryzmat tych pytań:
- Czy z umowy i załączników wynika, co dokładnie ma powstać, a co nie jest objęte zakresem?
- Czy harmonogram opisuje obowiązki obu stron i skutki opóźnień po każdej z nich?
- Czy model wynagrodzenia pasuje do sposobu prowadzenia projektu i czy obejmuje przeniesienie praw?
- Czy wiesz, kiedy i w jaki sposób aplikacja zostanie uznana za odebraną?
- Czy nabędziesz prawa autorskie w skutecznej formie, od kiedy i czy otrzymasz kod źródłowy oraz dostępy?
- Czy umowa przewiduje, jak wprowadzać zmiany zakresu?
- Czy wiesz, co się stanie, jeśli współpraca zakończy się przed czasem?
Jeśli na któreś z tych pytań nie znajdujesz odpowiedzi w umowie, nie oznacza to automatycznie, że umowa jest zła. Oznacza, że w tym obszarze ryzyko zostało przerzucone na przepisy ogólne albo na późniejsze negocjacje, zwykle w momencie, gdy Twoja pozycja jest już słabsza.
Umowa na stworzenie aplikacji mobilnej – podsumowanie
Umowa na stworzenie aplikacji mobilnej to nie formalność poprzedzająca development, tylko narzędzie zarządzania projektem i jego ryzykiem. Wzór przygotowany przez software house jest zwykle napisany rzetelnie, ale z perspektywy wykonawcy. To naturalne i nie świadczy o złej woli. Oznacza po prostu, że interesy zamawiającego trzeba zadbać samodzielnie.
Najważniejszy wniosek jest prosty: zanim podpiszesz umowę, sprawdź nie tylko, jak ma przebiegać projekt, ale także co się stanie, gdy przebiegnie inaczej. Właśnie w tych drugich scenariuszach umowa zaczyna mieć realne znaczenie.
Planujesz zlecić stworzenie aplikacji?
Jeśli otrzymałeś projekt umowy od software house’u albo chcesz przygotować własną umowę na stworzenie aplikacji mobilnej, kancelaria Prawnik dla IT może przeanalizować dokument pod kątem Twojego projektu i modelu współpracy. Wskażemy, które postanowienia warto zmienić przed podpisaniem i jak to uzasadnić w negocjacjach z wykonawcą. Skontaktuj się z nami, aby omówić swoją umowę.