Trzy modele rozliczenia w skrócie
- Fixed price
- Ustalasz zakres i cenę przed startem. Wykonawca dostarcza określony produkt, a zmiany zakresu wycenia się osobno.
- Time and material
- Płacisz za faktycznie przepracowane godziny według ustalonych stawek. Zakres może się zmieniać w trakcie, a Ty decydujesz o priorytetach.
- Model mieszany
- Stała cena za dobrze opisaną część, na przykład prototyp i pierwszą wersję, a reszta za czas pracy, zwykle z miesięcznym limitem godzin.
Porównanie modeli w jednej tabeli
| Kryterium | Fixed price | Time and material | Model mieszany |
|---|---|---|---|
| Budżet | Znany z góry, o ile zakres się nie zmienia. | Znany tylko w przybliżeniu. | Znany dla pierwszej wersji, dalej kontrolowany limitem. |
| Zmiany zakresu | Każda zmiana to wycena i aneks. | Łatwe, wchodzą do kolejnego etapu pracy. | Po pierwszej wersji łatwe. |
| Kto ponosi ryzyko pomyłki w szacunku | Głównie wykonawca, który zwykle dolicza bufor. | Głównie zamawiający. | Dzielone. |
| Twój nakład czasu | Duży na początku, przy opisie zakresu i odbiorze. | Stały, bo co tydzień ustalasz priorytety. | Duży na początku, potem regularny. |
| Kiedy pasuje | Strona firmowa, landing page, aplikacja po prototypie. | Produkt rozwijany po opiniach użytkowników, utrzymanie. | Większość nowych aplikacji. |
| Typowa pułapka | Spór o to, co mieściło się w zakresie. | Brak górnego limitu kosztów. | Niejasna granica między etapami. |
Ryzyka stałej ceny dla zamawiającego
- Wykonawca dolicza bufor na nieznane, więc przy prostym projekcie możesz przepłacić.
- Zakres opisany zbyt ogólnie, na przykład „panel klienta”, prowadzi do sporu przy odbiorze.
- Gdy budżet się kończy, presja czasu odbija się na testach i jakości kodu.
- Kodeks cywilny w art. 632 mówi, że przy wynagrodzeniu ryczałtowym wykonawca nie może żądać podwyższenia, nawet gdy rozmiaru prac nie dało się przewidzieć. Wyjątkiem jest nieprzewidziana zmiana stosunków grożąca rażącą stratą, gdy sąd może podwyższyć ryczałt albo rozwiązać umowę. Przepis dotyczy umowy o dzieło, a kwalifikacja umów IT bywa sporna.
- Każda zmiana zakresu wymaga wyceny i aneksu, co spowalnia reakcję na opinie użytkowników.
Ryzyka rozliczenia za czas pracy
- Brak górnego limitu: projekt może kosztować wyraźnie więcej, niż zakładał pierwszy szacunek.
- Płacisz także za błędy, poprawki i czas, w którym zespół uczy się Twojej branży.
- Trudno porównać oferty, bo sama stawka godzinowa nic nie mówi bez szacunku liczby godzin.
- Potrzebujesz osoby po swojej stronie, która regularnie ustala priorytety i sprawdza postępy.
- Jeśli umowa godzinowa zostanie uznana za umowę o świadczenie usług, stosuje się do niej przepisy o zleceniu (art. 750 Kodeksu cywilnego). Takie umowy co do zasady zobowiązują do starannego działania, a nie do konkretnego rezultatu.
Model mieszany w praktyce
- Klikalny prototyp i lista ekranów jako podstawa wyceny. Jak go zaplanować, piszemy we wpisie MVP aplikacji.
- Stała cena za pierwszą wersję z opisanym zakresem i kryteriami odbioru.
- Dalszy rozwój za czas pracy, z miesięcznym limitem godzin i raportem, na co poszły.
- Osobna umowa na opiekę po premierze. Co się na nią składa, opisujemy w tekście ile kosztuje utrzymanie aplikacji.
Jak porównywać oferty w różnych modelach
Oferta ze stałą ceną i oferta godzinowa wyglądają na nieporównywalne, ale da się je zestawić. Poproś wykonawcę rozliczającego się za czas o szacunek liczby godzin dla tej samej listy ekranów i funkcji, z podziałem na etapy, oraz o informację, jak bardzo ten szacunek może się zmienić. Od wykonawcy ze stałą ceną poproś o listę tego, co w cenie nie jest uwzględnione. Dopiero wtedy różnica w kwotach mówi coś o wykonawcy, a nie o tym, jak każdy z nich zrozumiał zakres.
Co wpisać do umowy niezależnie od modelu
- Zakres: lista ekranów i funkcji, a najlepiej prototyp jako załącznik.
- Kryteria i procedura odbioru: ile dni masz na testy, co jest błędem blokującym odbiór, a co drobną poprawką.
- Harmonogram i płatności za etapy, a nie całość z góry.
- Procedura zmian: każda zmiana zakresu dostaje wycenę i termin przed rozpoczęciem pracy.
- Przy rozliczeniu za czas: stawki, miesięczny limit, raport godzin i dostęp do repozytorium.
- Przeniesienie autorskich praw majątkowych do kodu i projektu. Wymaga formy pisemnej pod rygorem nieważności (art. 53 prawa autorskiego) i obejmuje tylko pola eksploatacji wyraźnie wymienione w umowie (art. 41 ust. 2). Warto określić, kiedy prawa przechodzą, na przykład z chwilą zapłaty.
- Kod w repozytorium na koncie Twojej firmy, a konta w sklepach, domena i serwery zarejestrowane na Ciebie.
- Lista bibliotek o otwartym kodzie i ich licencji, gwarancja, czas reakcji na błędy oraz umowa powierzenia przetwarzania danych osobowych.
- Zasady zakończenia współpracy: przekazanie kodu, dostępów i dokumentacji.
Ważne zastrzeżenie
Ten tekst nie jest poradą prawną. Opisujemy praktykę projektów IT i przytaczamy przepisy, które warto znać, ale każdą umowę, szczególnie zapisy o prawach autorskich, odpowiedzialności i karach umownych, powinien sprawdzić prawnik. Pytania, które warto zadać samemu wykonawcy, zebraliśmy we wpisie jak wybrać firmę tworzącą aplikacje.
Jak rozliczamy projekty w Tycode
Zaczynamy od bezpłatnego, klikalnego prototypu w 24 godziny. Na jego podstawie dostajesz wycenę na piśmie z listą ekranów i funkcji, a budowę dzielimy na etapy. Model rozliczenia dalszego rozwoju i opieki ustalamy z klientem osobno, żeby było jasne, za co płacisz po premierze. Czynniki wpływające na cenę opisujemy w poradnikach ile kosztuje aplikacja mobilna i ile kosztuje strona internetowa. Aplikacje zaczynają się u nas od 11 900 zł netto, a strony od 2 990 zł netto.
Źródła
Autor: Marcin Tyc, założyciel Tycode · opublikowano 21 października 2026 · aktualizacja 21 października 2026