Podpisujesz umowę na aplikację. Płacisz. A potem okazuje się, że nie wiesz, czy kod jest Twój. Albo że co miesiąc dokładasz, bo „wyszło trochę więcej godzin”. Znajome? Sposób rozliczenia to nie tylko kwestia budżetu. To decyzja o tym, kto co posiada i jak płacisz za zmiany.
W tym tekście: fixed price, time and material, rozliczenie pakietowe (jako rozwinięcie fixed po MVP) i abonament. Plus to, o co zadbać w umowie — żeby w modelach poza abonamentem było pełne przeniesienie praw autorskich, a przy abonamencie wiedzieć, że kupujesz dostęp na licencji, nie własność.
Fixed price — stała cena za zdefiniowany zakres
Fixed price oznacza: ustalacie zakres (specyfikację, listę funkcji), software house wycenia całość i płacisz stałą kwotę za dostarczenie tego zakresu. Budżet znany z góry. Ryzyko przerostu po stronie wykonawcy — jeśli coś się rozleci, to on dopłaca czasem, nie Ty.
Przykład z życia: Sieć trzech salonów fryzjerskich potrzebowała systemu rezerwacji online. Zamiast „chcę apkę do rezerwacji” — usiedli z wykonawcą i opisali: 6 ekranów (wybór salonu, data, godzina, usługa, dane klienta, potwierdzenie), mail z potwierdzeniem, prosty panel z listą rezerwacji na dziś i jutro. Specyfikacja na 4 strony. Wycena: 45 000 zł, dostawa w 10 tygodni. Klient wiedział, ile wyda i kiedy dostanie produkt. Żadnych niespodzianek w rachunku.
Odwrotny przykład: Ten sam klient gdyby przyszedł z „chcę apkę do rezerwacji” bez doprecyzowania — wykonawca albo odrzuciłby fixed (za duże ryzyko), albo wycenił wysoko „na zapas”. Albo po trzech miesiącach wyszłoby, że „panel dla franczyz” to 20 ekranów, nie 2 — i aneks, dopłata. Dlatego fixed wymaga doprecyzowania na starcie.
Minus: Zmiana scope’u w trakcie = zwykle aneks i dopłata. Dlatego fixed price często idzie w parze z MVP: najpierw robisz wersję minimalną (fixed), potem rozbudowujesz.
W umowie koniecznie: pełne przeniesienie praw autorskich do kodu i wszystkich wytworów projektu na Ciebie (lub Twoją firmę). Nie „licencja wyłączna”, tylko przeniesienie — wtedy produkt jest Twoją własnością. Znam przypadek, gdy w umowie było „przeniesienie praw po pełnej wpłacie”. Klient dopłacił ostatnią ratę — i dopiero wtedy dostał na piśmie potwierdzenie, że kod i dokumentacja przechodzą na niego. Bez tego zapisu mógłby tylko „używać”, nie sprzedać ani przenieść projektu. To nie drobnostka.
Time and material (T&M) — płacisz za czas
Time and material to rozliczenie za faktycznie przepracowane godziny (lub dni). Elastyczne: możesz zmieniać priorytety, dodawać funkcje, ciąć scope w locie. Idealne, gdy wymagania są płynne albo dopiero testujesz pomysł i nie chcesz zamykać się w sztywnej specyfikacji.
Przykład z życia: Startup z pomysłem na marketplace łączący wykonawców z klientami w niszowej branży. Na starcie nie było jasne: czy płatności od razu, czy na początek tylko „zapytania”; czy panel dla wykonawców ma być w pierwszej kolejności, czy landing dla klientów. Ustalili z SH T&M z capem 120 godzin na pierwsze 2 miesiące i cotygodniowe sync’y. Po 6 tygodniach okazało się, że klienci częściej wypełniają formularz „zapytaj” niż rejestrują się — przesunęli priorytet na powiadomienia i prosty CRM do zapytań. Gdyby fixed — musieliby aneksować. Przy T&M po prostu zmienili backlog. Rachunek za 2 miesiące: ok. 110 h — w granicach capu, produkt w rękach użytkowników.
Minus: brak sztywnego pułapu kosztów. Bez dobrej komunikacji i kontroli rachunki mogą urosnąć. Inny klient — bez capu i bez comiesięcznego przeglądu — po pół roku zobaczył faktury na 3× więcej, niż zakładał. Warto ustalić np. comiesięczny limit godzin albo „cap” na fazę i pilnować raportów (co zrobiono, ile godzin).
W umowie tak samo jak przy fixed: pełne przeniesienie praw autorskich do wytworzonego kodu i materiałów na zleceniodawcę. Płacisz za pracę — efekt pracy ma być Twoją własnością.
Rozliczenie pakietowe — fixed price po MVP, za pakiet ulepszeń
Pakietowe to w praktyce rozwinięcie fixed price po MVP. Masz już działający produkt (np. MVP). Zamiast otwierać wielką „fazę 2″ bez końca, ustalacie pakiety ulepszeń: np. „Pakiet A: panel admina + raporty”, „Pakiet B: integracja z płatnościami”. Za każdy pakiet — stała cena, jasny zakres, przewidywalny budżet.
Przykład z życia: Właściciel aplikacji do rezerwacji dla małych gabinetów (kosmetyka, fizjoterapia) miał MVP: formularz rezerwacji, kalendarz, mail z potwierdzeniem. Działało — ok. 200 rezerwacji miesięcznie w pierwszych 3 miesiącach. Zamiast „zróbmy teraz wszystko” ustalili z SH pakiety:
- Pakiet A (panel admina + eksport do CSV + podstawowe raporty): 22 000 zł, 6 tygodni.
- Pakiet B (integracja Stripe, płatność zaliczki online): 18 000 zł, 4 tygodnie.
- Pakiet C (powiadomienia SMS, przypomnienia): 12 000 zł, 3 tygodnie.
Wziął najpierw A — potrzebował raportów do księgowej. Po dwóch miesiącach dołożył B. Za każdy pakiet płacił z góry znaną kwotę. Żadnego nieskończonego T&M ani jednej wielkiej „fazy 2″ na 150 000 zł.
Korzyść: kontrola kosztów przy dalszym rozwoju. Nie musisz od razu specyfikować całego systemu. Wybierasz kolejny pakiet, gdy jesteś gotów — i znowu masz fixed na ten kawałek.
W umowie: pełne przeniesienie praw autorskich do kodu i materiałów wytworzonych w ramach pakietu na Ciebie. Każdy pakiet = Twoja własność, tak jak przy klasycznym fixed price.
Abonament — dostęp na licencji, nie własność
Abonament to inna bajka. Płacisz za dostęp do gotowego produktu (SaaS, platforma, narzędzie) lub za utrzymanie/wsparcie — ale nie nabywasz własności kodu. Korzystasz na licencji. Producent (software house lub dostawca) pozostaje właścicielem; Ty wykupujesz prawo użytkowania, zwykle w określonym zakresie (użytkownicy, moduły, czas).
Przykład z życia: Firma z flotą 15 samochodów (dostawy, serwis) potrzebowała systemu do śledzenia tras, tankowania i przeglądów. Zamiast budować własną aplikację — wykupiła abonament na gotową platformę do zarządzania flotą: ok. 500 zł netto / miesiąc za 15 pojazdów, wdrożenie w cenie, wsparcie w cenie. Nie ma własności kodu — ma dostęp. Po pół roku zmieniła model biznesu, zmniejszyła flotę i zrezygnowała z abonamentu. Dostęp wygasł. Dane (trasy, raporty) wyeksportowała w ciągu 30 dni — tak było zapisane w umowie. Gdyby wcześniej nie sprawdziła zapisów o eksporcie danych — mogłaby zostać bez kopii. Dlatego przy abonamencie czytaj: co z danymi po zakończeniu.
Kiedy ma sens: gdy nie chcesz inwestować w budowę i utrzymanie własnego systemu — tylko używać gotowego. Świadoma decyzja: wiesz, że to nie Twoja własność. Jeśli przestaniesz płacić — dostęp się kończy.
W umowie przy abonamencie nie ma pełnego przeniesienia praw — i tak ma być. Ważne, żeby było to zapisane wprost: co obejmuje licencja, na jak długo, co się dzieje z danymi po zakończeniu (eksport, okres przechowywania). Żadnych niedomówień.
Podsumowanie: własność vs dostęp
- Fixed price, T&M, pakiet: w umowie zadbaj o pełne przeniesienie praw autorskich do kodu i wytworów na siebie. Wtedy to Twoja własność.
- Abonament: płacisz za dostęp na licencji. To nie Twoja własność — i o to chodzi. Ważne, żeby warunki licencji i danych były jasne.
Wybierz model pod swój cel: przewidywalność (fixed / pakiet), elastyczność (T&M) czy gotowe narzędzie bez własnego kodu (abonament). I zawsze sprawdź zapisy o prawach — to nie detal, to fundament.
Chcesz dopasować sposób rozliczenia do swojego projektu? Porozmawiajmy — bez zobowiązań.
[Przycisk: Umów rozmowę / Kontakt] → wstaw blok Przycisk i podaj link do strony kontakt lub kalendarza
