Ile kosztuje utrzymanie aplikacji mobilnej — etat, freelancer czy pakiet godzin

Aplikacja jest w sklepie, pierwsi użytkownicy już ją mają, faktura za development zapłacona. I wtedy pada pytanie, na które większość właścicieli nie ma przygotowanej odpowiedzi: ile kosztuje utrzymanie aplikacji mobilnej, skoro „ona przecież już działa”?

Krótka odpowiedź: mniej, niż kosztuje programista na etacie, i więcej niż zero. Dłuższa odpowiedź zależy od tego, jak aktywnie aplikacja jest rozwijana, w jakiej technologii ją napisano i w jakim modelu kupujesz pracę. W tym tekście rozkładamy koszt utrzymania na części, pokazujemy, ile godzin miesięcznie potrzebują typowe aplikacje, i liczymy na przykładzie: etat, freelancer czy pakiet godzin w software housie.

Dlaczego aplikacja, która „działa”, i tak generuje koszty

Aplikacja mobilna nie żyje w próżni. Żyje na telefonach, których systemy zmieniają się co roku, w sklepach, które co roku zmieniają zasady, i na bibliotekach, które ktoś inny aktualizuje we własnym tempie. Nawet jeśli nie dodajesz żadnej funkcji, otoczenie aplikacji przesuwa się pod nią.

Konsekwencje bezczynności są bardzo konkretne:

• Google co roku podnosi wymagany poziom targetSdk. Aplikacja, która go nie spełni, przestaje być widoczna dla nowych użytkowników na nowszych Androidach. Opisaliśmy to szczegółowo w tekście o tym, dlaczego aplikacja znika z Google Play po terminie target API.
• Apple co roku wymaga budowania aplikacji w nowym Xcode i SDK. Bez tego nie wydasz żadnej aktualizacji — także pilnej poprawki błędu.
• Nowe wersje systemów zmieniają zachowanie aplikacji. Uprawnienia, powiadomienia, praca w tle, wygląd ekranu — to, co działało na zeszłorocznym Androidzie czy iOS, potrafi przestać działać na tegorocznym.
• Biblioteki i SDK zewnętrznych usług się starzeją. Bramki płatności, logowanie przez Google/Apple, SDK analityki — dostawcy wyłączają stare wersje API i nie pytają o zgodę.

Każdy rok bez aktualizacji nie oszczędza pieniędzy, tylko je odkłada — z odsetkami. Aplikacja zaniedbana przez dwa–trzy lata często nie daje się nawet zbudować i wymaga osobnego projektu reaktywacji, który kosztuje wielokrotnie więcej niż regularne, drobne podbicia wersji.

Z czego składa się koszt utrzymania aplikacji

Koszt utrzymania dzieli się na dwie bardzo różne kategorie: opłaty stałe, które są niewielkie i przewidywalne, oraz pracę ludzi, która stanowi zdecydowaną większość budżetu.

Opłaty stałe (niezależne od pracy)

• Konto Apple Developer Program — 99 USD rocznie. Bez aktywnego konta aplikacja znika z App Store.
• Konto Google Play Console — jednorazowa opłata 25 USD przy rejestracji.
• Backend i infrastruktura — serwer, baza danych, pliki, powiadomienia push. Od kilkudziesięciu złotych miesięcznie przy małej aplikacji na usługach typu Firebase do kilku tysięcy przy dużym ruchu i własnej infrastrukturze.
• Usługi zewnętrzne — mapy, SMS-y, e-maile transakcyjne, monitoring błędów, analityka. Wiele z nich ma darmowe progi, ale rosną razem z liczbą użytkowników.
• Prowizje sklepów — jeśli sprzedajesz treści cyfrowe przez zakupy w aplikacji. To nie koszt utrzymania w ścisłym sensie, ale warto go uwzględnić w budżecie.

Dla typowej aplikacji firmowej ta część to zwykle od kilkuset do kilku tysięcy złotych miesięcznie. Łatwo ją policzyć z faktur.

Praca programistów (główna część budżetu)

Tu mieści się wszystko, co wymaga człowieka:

• Utrzymanie obowiązkowe — podbijanie targetSdk i wersji iOS, aktualizacja bibliotek, dostosowanie do nowych wymagań sklepów, reakcja na odrzucenie aktualizacji.
• Naprawa błędów — zgłoszenia użytkowników, crashe z narzędzi monitorujących, problemy na konkretnych modelach telefonów.
• Bezpieczeństwo — aktualizacja zależności z podatnościami, odnawianie certyfikatów i kluczy, reagowanie na zmiany w logowaniu i płatnościach.
• Wydania — budowanie, testowanie i publikacja nowych wersji w obu sklepach.
• Rozwój — nowe funkcje, zmiany wynikające z feedbacku, dostosowanie do zmian w biznesie.

Pierwsze trzy punkty są nie do uniknięcia. Ostatni zależy wyłącznie od Twoich planów — i to on najmocniej różnicuje budżety.

Ile godzin miesięcznie potrzebuje aplikacja

Popularna reguła kciuka mówi, że roczny koszt utrzymania to 15–20% kosztu zbudowania aplikacji. To przydatny punkt odniesienia, ale mało precyzyjny — dwie aplikacje za tę samą kwotę mogą mieć zupełnie różne potrzeby. Lepiej myśleć godzinami pracy w miesiącu. Z naszego doświadczenia wynika mniej więcej taki podział:

• Aplikacja stabilna, bez planów rozwoju — około 10–30 godzin miesięcznie. Podbicia wersji, aktualizacje bibliotek, drobne poprawki, jedno–dwa wydania na kwartał. W niektórych miesiącach niemal nic, w okresie przed terminami Google i Apple — wyraźnie więcej.
• Aplikacja aktywna, z drobnym rozwojem — około 30–60 godzin miesięcznie. Do utrzymania dochodzą regularne poprawki z feedbacku, małe funkcje i wydania co kilka tygodni.
• Aplikacja rozwijana według roadmapy — około 80 godzin miesięcznie i więcej. Stały backlog, nowe funkcje w każdym wydaniu, praca na kilku frontach naraz.

Na liczbę godzin mocno wpływa kilka czynników:

• Liczba platform i baz kodu. Dwie natywne aplikacje (Android i iOS) to dwa zestawy aktualizacji. Aplikacja wieloplatformowa w Flutterze, React Native czy Kotlin Multiplatform zwykle jest tańsza w utrzymaniu, choć sam framework też trzeba regularnie aktualizować.
• Stan kodu. Brak testów, przestarzała architektura i nieaktualizowane od lat zależności sprawiają, że każda drobna zmiana trwa dłużej. To klasyczne odsetki od długu technicznego.
• Liczba integracji. Każda płatność, logowanie zewnętrzne czy SDK partnera to kolejna rzecz, która może się zmienić bez uprzedzenia.
• Automatyzacja wydań. Ręczne budowanie i wysyłanie wersji do sklepów potrafi zjeść kilka godzin przy każdym wydaniu. Dobrze ustawione CI/CD robi to samo w kilkanaście minut.

Etat, freelancer czy software house — trzy modele kosztowe

Liczba godzin to połowa równania. Druga połowa to sposób, w jaki za nie płacisz.

Programista na etacie lub stałym kontrakcie B2B

Doświadczony programista Android lub iOS na kontrakcie B2B to dziś zwykle 18–25 tys. zł netto miesięcznie. Na umowie o pracę całkowity koszt pracodawcy jest jeszcze wyższy.

• Plusy: pełna dostępność, wiedza o produkcie na miejscu, łatwa komunikacja.
• Minusy: płacisz za 160 godzin, nawet jeśli aplikacja potrzebuje 30. Dochodzi rekrutacja (często kilka miesięcy), wdrożenie, urlopy i choroby. Jedna osoba to jeden zestaw kompetencji — Androidowiec nie naprawi błędu w wersji iOS. A gdy odchodzi, wiedza odchodzi razem z nim.

Ten model ma sens, gdy aplikacja jest głównym produktem firmy i realnie wypełnia pełen etat pracy — albo więcej.

Freelancer na godziny

Najtańsza stawka godzinowa na papierze i największe ryzyko w praktyce.

• Plusy: elastyczność, płacisz za faktycznie przepracowany czas.
• Minusy: dostępność zależy od innych zleceń freelancera, więc pilna poprawka może czekać tygodniami. Brak zastępstwa na urlop czy chorobę. Jeśli współpraca się urywa, a dostępy do sklepów, repozytorium i serwerów były na jego kontach, masz poważny problem — dokładnie taki scenariusz opisujemy w checkliście przejęcia projektu.

Ten model działa, gdy masz sprawdzonego specjalistę i wszystkie dostępy trzymasz po swojej stronie.

Software house w modelu godzinowym (outsourcing utrzymania)

Programista z zewnętrznej firmy, wdrożony w Twój projekt, pracuje ustaloną liczbę godzin w miesiącu: stały pakiet (np. 30 godzin), pół etatu (około 80 godzin) albo na żądanie.

• Plusy: płacisz za tyle godzin, ile aplikacja potrzebuje, i zmieniasz wymiar, gdy zmieniają się potrzeby. Ciągłość pracy zapewnia firma, nie Ty. W razie potrzeby masz dostęp do QA, designu czy backendu bez zatrudniania kolejnych osób.
• Minusy: stawka godzinowa jest wyższa niż u freelancera. Trzeba zadbać, żeby do projektu była przypisana stała osoba, a nie co miesiąc ktoś nowy — inaczej płacisz za ciągłe wdrażanie się w kod.

Policzmy na przykładzie

Weźmy aplikację firmową na Androida i iOS, z umiarkowanym rozwojem. Dla uproszczenia przyjmijmy przykładową stawkę 180 zł netto za godzinę w software housie (realne stawki na rynku się różnią — to tylko ilustracja mechanizmu) i 22 tys. zł miesięcznie za programistę na B2B.

Wariant 1 — własny programista na pełen etat: 22 000 zł × 12 miesięcy = 264 000 zł rocznie, niezależnie od tego, ile pracy faktycznie było. Do tego koszt rekrutacji i ryzyko, że przy odejściu tej osoby zaczynasz od zera.

Wariant 2 — pół etatu w software housie (80 h/mies.): 80 h × 180 zł = 14 400 zł miesięcznie, czyli 172 800 zł rocznie. Stały rytm rozwoju, backlog, regularne wydania.

Wariant 3 — stały pakiet 30 godzin miesięcznie: 30 h × 180 zł = 5 400 zł miesięcznie, czyli 64 800 zł rocznie. Wystarcza aplikacji w fazie utrzymania z drobnymi zmianami.

Różnica między wariantem 1 a 3 to prawie 200 tys. zł rocznie — przy aplikacji, która i tak nie wypełniłaby pełnego etatu. To właśnie dlatego firmy, które przechodzą z etatu na model godzinowy, schodzą z kosztem utrzymania nawet o połowę.

Uczciwie trzeba dodać: jeśli Twoja aplikacja potrzebuje 160 godzin pracy miesięcznie i więcej, rachunek się odwraca i własny zespół staje się rozsądniejszy. Model godzinowy wygrywa tam, gdzie pracy jest mniej niż pełen etat — a to przypadek większości aplikacji firmowych.

Na czym nie oszczędzać

Szukając oszczędności, łatwo obciąć rzeczy, które potem wracają jako znacznie większy rachunek:

• Coroczne podbicia wersji. Odkładanie ich o rok czy dwa sprawia, że zamiast jednej zmiany robisz kilka naraz — często z przebudową fragmentów aplikacji.
• Monitoring błędów. Bez narzędzia zbierającego crashe dowiadujesz się o problemach z ocen w sklepie, czyli za późno.
• Dostępy po Twojej stronie. Konta w App Store Connect i Google Play Console, repozytorium, klucze podpisujące aplikację i serwery powinny należeć do Twojej firmy. Odzyskiwanie ich po zniknięciu wykonawcy bywa droższe niż cały rok utrzymania.
• Testy przed wydaniem. Wydanie z błędem to nie tylko koszt poprawki, ale też utrata ocen i użytkowników.

Jak obniżyć koszt utrzymania aplikacji mobilnej

Kilka rzeczy, które realnie zmniejszają liczbę godzin potrzebnych każdego miesiąca:

1. Aktualizuj małymi krokami, regularnie. Podbicie jednej biblioteki o jedną wersję zajmuje chwilę. Podbicie dwudziestu bibliotek o trzy wersje naraz potrafi zająć tygodnie.
2. Zautomatyzuj budowanie i wydania. CI/CD i narzędzia takie jak fastlane eliminują ręczną pracę przy każdym wydaniu i ograniczają pomyłki.
3. Dodaj testy tam, gdzie najczęściej coś się psuje. Nie trzeba pokrycia testami całej aplikacji — wystarczą kluczowe ścieżki: logowanie, płatność, główna funkcja.
4. Usuń to, czego nikt nie używa. Każda nieużywana biblioteka i martwy ekran to coś, co i tak trzeba aktualizować.
5. Zacznij od przeglądu stanu kodu. Jednorazowy audyt pokazuje, co generuje największe koszty, i pozwala zaplanować utrzymanie na liczbach, a nie na przeczuciu.

Kiedy własny programista, a kiedy outsourcing utrzymania

W skrócie:

• Własny programista — gdy aplikacja jest Twoim głównym produktem, pracy jest na pełen etat lub więcej i chcesz budować zespół wewnątrz firmy.
• Freelancer — gdy masz sprawdzoną osobę, niewielkie i nieregularne potrzeby, a wszystkie dostępy trzymasz u siebie.
• Software house na godziny — gdy aplikacja potrzebuje od kilkunastu do kilkudziesięciu godzin miesięcznie, zależy Ci na ciągłości i nie chcesz rekrutować ani zarządzać programistą.

Jeśli nie wiesz, do której grupy należysz, sprawdź, ile godzin pracy faktycznie trafiło do aplikacji w ostatnim roku. To zwykle najszybsza odpowiedź.

Podsumowanie

Utrzymanie aplikacji mobilnej to nie opcja, tylko warunek, żeby aplikacja w ogóle została w sklepach i działała na nowych telefonach. Opłaty stałe są niewielkie. O budżecie decyduje praca — a przede wszystkim to, czy płacisz za godziny, których aplikacja naprawdę potrzebuje, czy za pełen etat „na wszelki wypadek”.

Dla większości aplikacji firmowych wystarcza od kilkunastu do kilkudziesięciu godzin miesięcznie. W takim wymiarze prowadzimy utrzymanie aplikacji mobilnych na Androida, iOS i we Flutterze — w pakiecie godzin, na pół etatu albo na żądanie. Zaczynamy od darmowej analizy projektu, po której wiesz, ile godzin realnie potrzebujesz. Jeśli aplikacja od dawna nie była aktualizowana, zacznij od naszej checklisty 15 punktów albo po prostu napisz do nas.