Ile kosztuje aplikacja mobilna: jak rozłożyć wycenę na czynniki

Ile kosztuje aplikacja mobilna — odpowiedź nie bierze się z cennika, tylko z tego, co dokładnie ktoś policzył. Kwota na ofercie to iloczyn ról, stawek godzinowych i godzin, powiększony o pozycje jednorazowe oraz o koszty, które wracają co miesiąc. Dlatego dwa studia potrafią wycenić ten sam pomysł kilkukrotnie różnie i obie kwoty mogą być policzone uczciwie. Ten tekst nie jest cennikiem: pokazuje metodę, dzięki której rozłożysz cudzą wycenę na czynniki i zapytasz o pozycje, których w niej brakuje.

Dlaczego dwie wyceny tego samego projektu różnią się kilkukrotnie

Bo wyceniają różny zakres, a nie ten sam produkt w dwóch cenach. Publikowane w sieci widełki kosztu aplikacji rozjeżdżają się między wydawcami tak mocno, że nie da się z nich zbudować żadnego punktu odniesienia — każdy liczy coś innego i prawie nikt nie pokazuje, jak z godzin powstała kwota.

Różnice biorą się z czterech miejsc: z zakresu (ile ekranów, ile ról użytkownika, czy jest panel administracyjny), z tego, co wliczono w cenę poza programowaniem, ze stawki godzinowej oraz z bufora na ryzyko. Zanim porównasz kwoty, musisz wiedzieć, że obie oferty opisują ten sam produkt. Decyzja o tym, co wchodzi do pierwszej wersji, jest tu ważniejsza niż negocjacja stawki — rozstrzyga ją zakres MVP aplikacji, nie cennik wykonawcy.

Ile kosztuje aplikacja mobilna w rozbiciu na role, stawki i godziny

Kwota na ofercie to suma trzech warstw: pracy rozliczanej godzinowo, pozycji jednorazowych i kosztów cyklicznych. Pierwsza warstwa jest największa i liczy się ją zawsze tak samo: rola razy stawka razy liczba godzin.

Stawka godzinowa fakturowana klientowi przez polskie studia programistyczne była w 2026 r. podawana przez agregatory ofert cenauslug.pl i digitay.pl na poziomie średnio około 170 zł netto za godzinę, przy rozpiętości 110-240 zł/h zależnie od miasta. To dane agregatorów cen usług, nie badanie branżowe — traktuj je jako rząd wielkości do rozmowy, nie jako obowiązujący punkt odniesienia. Te same źródła zaznaczają, że role analityczne, UX/UI oraz architekci bywają wyceniane wyżej niż programiści.

Stawka fakturowana klientowi to nie to samo co wynagrodzenie programisty. Mieszczą się w niej także praca kierownika projektu i testera, urlopy, rekrutacja, ryzyko oraz gwarancja na wykonany kod. Liczba godzin to również co innego niż czas trwania projektu w kalendarzu, bo prace potrafią biec równolegle albo czekać na decyzje po stronie zamawiającego — ile trwa stworzenie aplikacji mobilnej zależy od zupełnie innych czynników niż to, ile godzin obejmuje wycena.

Praca, która nie jest programowaniem, a i tak jest w budżecie

W każdym projekcie aplikacji istotna część godzin przypada na role, które nie piszą kodu produkcyjnego. Analiza wymagań, projekt interfejsu, testy, zarządzanie projektem i konfiguracja środowisk to praca, która musi się wydarzyć niezależnie od tego, czy ktoś ją pokazał w ofercie.

Typowy zestaw ról w wycenie wygląda tak:

• analityk lub product owner — spisanie wymagań, scenariusze użycia, kryteria akceptacji,
• projektant UX/UI — architektura informacji, makiety, projekt graficzny, stany błędów,
• programista — implementacja, przeglądy kodu, poprawki po testach,
• tester (QA) — scenariusze testowe, testy na urządzeniach, testy regresji przed każdym wydaniem,
• kierownik projektu — planowanie, komunikacja, raportowanie, zarządzanie zmianą zakresu,
• DevOps — środowiska, wydania do sklepów, monitoring.

Gdy w ofercie widzisz wyłącznie godziny programistów, to nie znaczy, że pozostałe role nie będą potrzebne. Znaczy, że albo ukryto je w stawce, albo wrócą jako prace dodatkowe. Kolejność, w jakiej te role wchodzą do projektu, opisuje osobny tekst o tym, jak stworzyć aplikację mobilną od pomysłu do wydania.

Siedem pozycji, których nie widać w ofercie

To są pozycje, które najczęściej wracają jako „prace dodatkowe”, bo nikt nie zapytał o nie na etapie wyceny. Przejdź tę listę przy każdej ofercie:

1. Zarządzanie projektem — planowanie, spotkania statusowe, raporty, obsługa zmian zakresu. Jeśli nie ma tej pozycji, sprawdź, czy jest doliczona procentowo do godzin zespołu.
2. Testy — nie tylko wykonanie testów, ale też czas programistów na poprawki i ponowną weryfikację. Wycena bez pozycji na poprawki jest wyceną niekompletną.
3. Migracja danych — przeniesienie kont, historii zamówień czy kartotek z obecnego systemu. Przy wdrożeniach ERP i CRM migracja bywa wyceniana osobno, obok integracji i szkoleń.
4. Integracje z systemami klienta — każdy system po Twojej stronie to osobna praca, a często też osobne licencje i limity API; koszt zależy od tego, jak wygląda integracja systemów w firmie i czy dostawca udostępnia gotowe API.
5. Licencje narzędzi i usług — mapy, płatności, powiadomienia push, wysyłka e-maili i SMS, narzędzia analityczne. Część z nich rozlicza się od zużycia, więc rośnie razem z liczbą użytkowników.
6. Wsparcie po wdrożeniu — okres gwarancji, czas reakcji, kanał zgłoszeń. Gwarancja na błędy to nie to samo co rozwój nowych funkcji.
7. Konta deweloperskie i infrastruktura — konto w Google Play Console kosztuje jednorazowo 25 USD, a Apple Developer Program 99 USD rocznie. Do tego dochodzi serwer, baza danych, domena, certyfikaty i kopie zapasowe.

Fixed price, time and materials czy fixed budget — który model Cię chroni

Model rozliczenia decyduje o tym, kto ponosi ryzyko błędnego oszacowania. W polskich projektach IT stosuje się trzy warianty: fixed price, time and materials oraz hybrydę zwaną fixed budget, czyli rozliczenie godzinowe z górnym limitem budżetu, dopuszczające zmiany zakresu bez osobnych zamówień (opis modeli: mobitouch.net, 1 lutego 2024).

Przy fixed price wykonawcy doliczają do wyceny bufor na nieprzewidziane okoliczności — mobitouch.net podawał 1 lutego 2024 rząd wielkości około 30%. To nie jest norma branżowa ani stawka obowiązkowa, tylko opis praktyki jednego wydawcy; potraktuj to jako powód, żeby zapytać wprost, jaki bufor siedzi w Twojej ofercie. Ten sam serwis zauważa, że fixed price bywa wymuszony przy projektach finansowanych z dotacji, bo budżet z wniosku jest sztywny. O tym, czy w Twoim projekcie lepiej sprawdzi się fixed price czy time and material, decyduje dojrzałość zakresu, a nie wielkość budżetu — i to od modelu zależy, jak umowa opisze procedurę zmiany zakresu oraz kryteria odbioru.

Jak sformułować zapytanie, żeby oferty dały się porównać

Wycenę porównywalną dostaje ten, kto sam narzuci strukturę odpowiedzi. Zamiast pytać o cenę, poproś o rozbicie na role, godziny i pozycje jednorazowe oraz o wyraźną listę wykluczeń. Taką strukturę narzuca zapytanie ofertowe na oprogramowanie z kryteriami oceny i wymaganym formatem odpowiedzi.

Reszta jakości wyceny zależy od tego, co sam opiszesz: cel biznesowy, użytkowników, listę funkcji i ograniczenia — czyli od tego, jak napisać brief dla software house. Jeśli wolisz mieć to uporządkowane bez pisania dokumentu od zera, przejdź przez kreator briefu i wyślij gotowy opis do wszystkich wykonawców w tej samej formie.

Koszty, które zaczynają się dopiero po wdrożeniu

Aplikacja generuje koszty także wtedy, gdy nikt jej nie rozwija. Standardowy zakres utrzymania to monitoring dostępności, aktualizacje bezpieczeństwa, kopie zapasowe i obsługa zgłoszeń zgodnie z SLA; rozwój nowych funkcji jest osobnym budżetem i osobną umową. To, czy te prace może przejąć inny wykonawca, zależy od tego, czy umowa przeniosła na Twoją firmę prawa autorskie do kodu — bez tego zapisu zmiana dostawcy oznacza pisanie części aplikacji od nowa.

Do tego dochodzą prace wymuszone z zewnątrz. Od 31 sierpnia 2026 Google Play wymaga od nowych aplikacji i od aktualizacji targetowania Androida 16 (API 36) — to godziny, które trafiają do budżetu utrzymania niezależnie od tego, czy właściciel zmienia w aplikacji cokolwiek. Podobnie działają aktualizacje bibliotek i zależności, wycofywane wersje systemów oraz zmiany w regulaminach sklepów.

W sieci krąży reguła kciuka mówiąca, że utrzymanie kosztuje 10-20% kosztu wytworzenia rocznie. Nie stoi za nią żadne badanie, do którego dałoby się odesłać, więc nie używaj jej jako pozycji w budżecie. Zamiast tego rozbij ją na składniki, które da się policzyć: hosting i baza danych, monitoring, certyfikaty i domeny, licencje usług zewnętrznych rozliczane od zużycia, odnowienie Apple Developer Program za 99 USD rocznie, godziny na aktualizacje techniczne oraz godziny na obsługę zgłoszeń w ramach SLA.

Jak porównać dwie oferty, które nie wyglądają podobnie

Sprowadź obie do jednej tabeli pozycji i porównuj wiersz po wierszu, nie kwotą końcową. Wypisz w kolumnie po lewej wszystkie pozycje z tego tekstu — role z godzinami, siedem pozycji ukrytych, model rozliczenia, bufor, koszty cykliczne — i poproś każdego wykonawcę o uzupełnienie tych samych wierszy.

Puste pole jest równie ważne jak wypełnione: oznacza pozycję, która albo jest out of scope, albo nie została w ogóle przemyślana. Gdy tabela jest kompletna, różnica między ofertami sama się tłumaczy i zwykle sprowadza się do jednego z trzech powodów: innego zakresu, innej stawki albo innego podziału ryzyka. Gdy pozycje się już zgadzają, decyzja przenosi się z kwoty na to, jak wybrać software house po odpowiedziach na pytania o zespół, proces i ryzyko.

Jeśli różnica wynika z zakresu, wróć do listy funkcji i przytnij ją do zakresu pierwszej wersji, zamiast szukać tańszego wykonawcy do tego samego. Jeśli wynika z założeń, których nikt nie spisał, problem leży po stronie zapytania — uzupełnij brief dla software house i poproś o korektę wyceny na tych samych danych. Cena, której nie umiesz rozłożyć na pozycje, nie jest informacją, tylko liczbą.