Umowa na wykonanie aplikacji. Siedem punktów, których brak kosztuje najwięcej

Najdroższe zdania w umowie na wykonanie aplikacji to te, których w niej nie ma. Nie jestem prawnikiem i tego tekstu nie należy traktować jak porady prawnej — piszę z drugiej strony stołu, jako wykonawca, który widzi, co się psuje, gdy któregoś punktu zabrakło.

Siedem rzeczy, które warto sprawdzić, zanim podpiszesz.

1. Przeniesienie praw autorskich, nie licencja

To jest różnica między posiadaniem aplikacji a wynajmowaniem jej. Umowa powinna mówić o przeniesieniu autorskich praw majątkowych na wskazanych polach eksploatacji, a nie o udzieleniu licencji.

Przy licencji wykonawca zostaje właścicielem i teoretycznie może ograniczyć Ci korzystanie albo policzyć za rozszerzenie zakresu. Przy przeniesieniu praw aplikacja jest Twoja i możesz z nią zrobić wszystko, łącznie z odsprzedaniem.

Sprawdź też moment przeniesienia. Jeśli prawa przechodzą „z chwilą zapłaty całości wynagrodzenia", a projekt utknie na ostatniej racie, zostajesz z kodem, do którego nie masz praw.

2. Kod źródłowy i miejsce, gdzie leży

Prawa autorskie bez kodu są warte tyle, co akt własności domu bez klucza. Umowa powinna wskazywać, że dostajesz kod źródłowy, i najlepiej — że trafia on do Twojego repozytorium na bieżąco, a nie w archiwum po odbiorze.

Różnica jest praktyczna: kod przekazany na końcu bywa niekompletny, bo brakuje w nim konfiguracji, skryptów uruchomieniowych i historii zmian. Kod trafiający na bieżąco do Twojego repozytorium jest kompletny z definicji.

3. Konta i infrastruktura założone na Ciebie

Konto deweloperskie w App Store i Google Play, hosting, baza danych, domena, operator płatności, wysyłka powiadomień. Każde z nich powinno należeć do firmy, nie do wykonawcy.

To jeden z najczęstszych punktów zapalnych przy zmianie wykonawcy. Jeśli aplikacja jest opublikowana na koncie software house'u, przeniesienie jej na Twoje konto bywa procedurą na tygodnie, a czasem oznacza publikację od nowa i utratę ocen.

4. Zakres i kryteria odbioru

Załącznik z listą funkcji jest ważniejszy niż sama umowa. Bez niego spór o to, czy coś „miało być", jest nierozstrzygalny i zawsze kończy się źle dla obu stron.

Trzy rzeczy, które warto tam zapisać:

• Lista funkcji podzielona na etapy, z terminem i kwotą przypisaną do każdego etapu.
• Kryterium odbioru opisane czynnością, nie oceną. „Użytkownik rezerwuje termin i otrzymuje powiadomienie" da się sprawdzić. „Aplikacja działa poprawnie" nie.
• Termin na zgłoszenie uwag. Bez niego odbiór ciągnie się miesiącami, a wykonawca nie wie, kiedy skończył.

5. Tryb zmiany zakresu

Zakres zmieni się w trakcie — to normalne i lepiej to założyć, niż udawać, że nie. Umowa powinna opisywać, co się wtedy dzieje: kto zgłasza zmianę, kto ją wycenia, w jakim terminie i jak wygląda akceptacja.

Brak tego punktu prowadzi do dwóch skrajności. Albo wykonawca dokłada wszystko za darmo i traci na projekcie, przez co traci też zaangażowanie. Albo każda drobna zmiana staje się negocjacją i projekt zwalnia.

6. Gwarancja i granica między błędem a nową funkcją

Ta granica musi być w umowie, bo po odbiorze staje się najczęstszym źródłem nieporozumień.

Zasada, którą stosuję: błąd to rozbieżność między tym, co działa, a tym, co było w uzgodnionym zakresie — poprawiam w ramach gwarancji, bez dodatkowej opłaty. Nowa funkcja to coś, czego w zakresie nie było — wyceniam osobno. Warto zapisać też długość gwarancji i czas reakcji na zgłoszenie.

7. Wyjście ze współpracy

Najmniej przyjemny punkt do negocjowania i najbardziej wartościowy. Umowa powinna mówić, co się dzieje, gdy któraś strona chce zakończyć: jaki jest okres wypowiedzenia, jak rozliczany jest etap w toku i co dokładnie wykonawca przekazuje.

Przy wykonawcy jednoosobowym dochodzi pytanie o ciągłość. Sam zabezpieczam je tak, że kod jest w Twoim repozytorium od pierwszego dnia, infrastruktura na Twoich kontach, a dokumentacja techniczna stanowi część odbioru. Dzięki temu przejęcie projektu przez kogoś innego nie wymaga archeologii — i to samo działa, gdy po prostu chcesz zmienić wykonawcę.

Jeszcze jedno: dane osobowe

Jeśli aplikacja przetwarza dane osobowych klientów, a wykonawca ma do nich dostęp, potrzebna jest umowa powierzenia przetwarzania. To osobny dokument, nie punkt w umowie głównej. Warto zapytać o niego wprost, bo jego brak jest problemem po Twojej stronie, nie wykonawcy.

Krótko

• Przeniesienie praw autorskich, nie licencja. Sprawdź moment przeniesienia.
• Kod źródłowy trafiający do Twojego repozytorium na bieżąco, nie po odbiorze.
• Wszystkie konta i infrastruktura założone na Twoją firmę.
• Załącznik z funkcjami i kryteriami odbioru opisanymi czynnością.
• Opisany tryb zmiany zakresu i granica między błędem a nową funkcją.
• Warunki wyjścia ze współpracy uzgodnione, zanim będą potrzebne.

Jak wygląda to u mnie w praktyce, opisałem na stronie oprogramowania na zamówienie.