Najdroższe zdania w umowie to te, których w niej nie ma. Siedem punktów, które decydują o tym, czy aplikacja naprawdę będzie Twoja.
Ładuję treść…
Mateusz Przybysz — buduję firmom aplikacje web i mobile. Odpowiadam za weryfikację merytoryczną i publikację tego tekstu.
Opublikowano 6 lipca 2026.
To, o co czytelnicy dopytują najczęściej po lekturze.
Przy budowie aplikacji naturalna jest umowa o dzieło z przeniesieniem praw autorskich: umawiacie się na konkretny, odbieralny rezultat, a nie na staranne działanie. To po Twojej stronie ważne, bo daje podstawę do odbioru i do reklamacji. Konkretną kwalifikację warto potwierdzić z księgowością albo prawnikiem — ma znaczenie podatkowe po obu stronach.
Rynkowo 20–40% na start, reszta w ratach powiązanych z etapami. Podział na etapy jest ważniejszy niż sama wysokość zaliczki: przy trzech płatnościach powiązanych z odbiorami obie strony mają na czym się oprzeć. Uważaj na dwa skrajne układy: pełna płatność z góry i pełna płatność po odbiorze. Pierwszy zdejmuje z wykonawcy presję, drugi zwykle oznacza, że koszt tego ryzyka jest już doliczony do ceny.
Przy projektach do kilkunastu tysięcy złotych zwykle wystarczy uważne przeczytanie siedmiu punktów z tego wpisu i dopytanie wykonawcy o to, co niejasne. Przy większych kwotach, przy danych osobowych klientów albo przy projekcie, który ma być podstawą działania firmy — tak, warto. Godzina pracy prawnika kosztuje ułamek tego, co spór o prawa do kodu.
Widełki „od 5 000 do 500 000 zł" nie mówią nic. Rozbijam cenę aplikacji na składniki i pokazuję, co realnie decyduje o kwocie w wycenie.
Abonament wygląda tanio, dopóki nie pomnożysz go przez liczbę osób i przez pięć lat. Ale tanio nie znaczy źle — pokazuję, gdzie leży próg.
Nie „kilka tygodni". Rozpisany harmonogram z etapami, terminami weryfikacji w sklepach i trzema miejscami, w których projekty realnie się zatrzymują.
Napisz w dwóch zdaniach, co robicie dziś ręcznie. W 24h odeślę pomysł i widełki. Za darmo.
lub napisz bezpośrednio:[email protected]
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.
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.
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.
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.
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ć:
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.
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.
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ę.
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.
Jak wygląda to u mnie w praktyce, opisałem na stronie oprogramowania na zamówienie.
