Koszt utrzymania aplikacji React Native w 2026

Jeśli aplikacja React Native jest już w produkcji, budżet utrzymaniowy nie powinien być resztką po projekcie. To osobny plan operacyjny: aktualizacje systemów, zgodność z wymaganiami sklepów, obsługa błędów i awarii, testy regresji i drobna lista prac po starcie.

Dla większości aplikacji biznesowych sensowny punkt startu to EUR 2 500 - 6 000 miesięcznie przy pakiecie 20-60 godzin. Prostsza aplikacja z Expo i kilkoma ekranami może zmieścić się bliżej dolnej granicy. Aplikacja sprzedażowa, firmowa, logistyczna albo finansowa z finalizacją zamówienia, wieloma połączeniami z systemami i krótkim czasem reakcji będzie bliżej 40-60 godzin lub wyżej.

Najdroższy scenariusz to nie stały pakiet. Najdroższy scenariusz to brak właściciela utrzymania, przestarzałe biblioteki zewnętrznych dostawców, odrzucona wersja w App Store tydzień przed kampanią i zespół, który zaczyna od rozpoznawania cudzego kodu.

Utrzymanie techniczne obejmuje aktualizacje React Native, narzędzi Expo, Xcode, wtyczki Android Gradle, docelowego poziomu Androida, zależności npm, certyfikatów, konfiguracji wydań i poprawek bezpieczeństwa. To nie są zadania kosmetyczne: Apple i Google regularnie zmieniają minimalne wymagania dla nowych wersji aplikacji.

Utrzymanie jakości obejmuje narzędzia do rejestrowania awarii, takie jak Sentry lub Firebase Crashlytics, alerty po spadku liczby sesji bez awarii, analizę zawieszeń Androida, sprawdzanie czasu startu aplikacji oraz testy regresji logowania, ścieżki zakupu, płatności, powiadomień, linków głębokich i zdarzeń analitycznych.

Utrzymanie produktowe obejmuje małe zmiany w ramach godzin: teksty, baner, walidację formularza, drobny ekran, zdarzenie analityczne w Google Analytics 4 lub Segment, poprawkę interfejsu po zmianie umowy technicznej. Nowy moduł lojalnościowy, połączenie z systemem finansowo-magazynowym, bazą produktów lub systemem magazynowym albo przebudowa ścieżki zakupu to już osobny zakres po rozpoznaniu biznesu, projektu i technologii.

Plan 20 godzin, zwykle EUR 2 500 - 3 500 miesięcznie, pasuje do stabilnej aplikacji z jednym zapleczem, małą liczbą integracji, brakiem ścieżki zakupu krytycznej dla przychodu i rozsądną dokumentacją po wdrożeniu.

Plan 40 godzin, zwykle EUR 3 500 - 5 000 miesięcznie, jest najczęstszy dla aplikacji sprzedażowych, firmowych i operacyjnych. Daje miejsce na obsługę błędów, aktualizację bibliotek, testy regresji, małe zmiany oraz szybką reakcję, gdy zaplecze, płatności albo sklep z aplikacjami wymuszą zmianę.

Plan ponad 60 godzin, zwykle EUR 5 000 - 8 000+ miesięcznie, jest uzasadniony przy wysokim ruchu, wielu wariantach aplikacji, płatnościach, kilku środowiskach, niestandardowych modułach natywnych, energooszczędnej komunikacji Bluetooth, urządzeniach połączonych z internetem, sezonowości sprzedażowej, zgodności regulacyjnej albo czasie reakcji zbliżonym do systemów krytycznych dla działania firmy.

Koszt rośnie, gdy aplikacja ma niestandardowe moduły natywne, nietypowe biblioteki płatności, tryb pracy bez internetu, wiele marek, kilka krajów, wymóg publikacji pod różnymi kontami sklepów albo zaplecze bez wersjonowania umowy technicznej.

Koszt rośnie również wtedy, gdy poprzedni zespół zostawił mało testów, brak instrukcji publikacji, brak kont pokazowych dla recenzentów, ręczny sposób wydawania wersji, niestabilne budowanie aplikacji w Expo lub Xcode albo narzędzie do zgłaszania awarii, które zbiera błędy, ale nikt ich nie analizuje.

Koszt spada, gdy aplikacja używa Expo tam, gdzie to ma sens, ma dobre środowisko testowe, automatyczne wydania, listę kontrolną publikacji, testy krytycznych przepływów, opis architektury i listę prac posegregowaną na awarie, utrzymanie i nowe funkcje.

Umowa utrzymaniowa musi rozróżniać typy awarii. Krytyczna awaria to niedostępna aplikacja, zepsuta ścieżka zakupu, masowe błędy albo brak możliwości logowania; reakcja powinna być liczona w godzinach. Normalny błąd bez wpływu na sprzedaż może mieć czas reakcji 24-48 godzin w dni robocze.

Kalendarz aktualizacji powinien zawierać co najmniej: kwartalny przegląd zależności, zaplanowane aktualizacje narzędzi Expo, roczną większą aktualizację React Native, śledzenie wymagań Apple, docelowy poziom Androida w Google Play i zamrożenie funkcji przed pikami sprzedaży.

Oficjalne dokumentacje React Native i Expo rekomendują aktualizacje krok po kroku, a Expo zwraca uwagę, że aplikacje produkcyjne powinny używać własnych kompilacji deweloperskich zamiast polegać na Expo Go dla starszych wersji zestawu narzędzi. To argument za planem, a nie za odkładaniem aktualizacji.

Sam dostęp do Sentry albo Firebase Crashlytics nie jest utrzymaniem. Utrzymaniem jest rytm: ktoś przegląda błędy, grupuje regresje, porównuje sesje bez awarii, sprawdza najczęstsze urządzenia i decyduje, co wchodzi do najbliższej publikacji.

Raport miesięczny powinien pokazywać użytkowników i sesje bez awarii, 5 najczęstszych grup błędów, zawieszenia Androida, czas startu aplikacji, błędy umowy technicznej, procent nieudanych płatności, status sklepów, ryzykowne zależności oraz listę prac utrzymaniowych na kolejny miesiąc.

Dla dyrektora finansowego raport powinien odpowiadać na pytanie: co kupiły godziny utrzymaniowe? Dla dyrektora technicznego: czy ryzyko produkcyjne maleje, czy rośnie? Dla właściciela produktu: które małe zmiany naprawdę poprawiają adopcję.

Aplikacja sprzedażowa nie kończy się na ekranach. Żyje na przecięciu katalogu, promocji, płatności, systemu finansowo-magazynowego, magazynu, powiadomień, relacji z klientami i analityki. Jedna zmiana w zapleczu może złamać koszyk, status zamówienia albo kupon.

W sprzedaży firmowej dochodzą role użytkowników, cenniki z umów, limity kredytowe, zamówienia powtarzalne, akceptacja zamówień i połączenia z systemami, które często nie były projektowane z myślą o kanale mobilnym. To podnosi koszt regresji i testów.

W projekcie SFD po starcie liczyły się nie tylko poprawki błędów, ale też utrzymanie jakości w sklepach, aktualizacje iOS/Androida i stabilność podczas szczytów ruchu. Przy 100k+ pobrań i ocenie 4.9 utrzymanie aplikacji jest częścią produktu, nie dodatkiem.

W GMI traktujemy utrzymanie jako kontynuację odpowiedzialności produktowej. Po rozpoznaniu biznesu, projektu i technologii oraz po realizacji zespół zna architekturę, decyzje techniczne, ryzyka i cele biznesowe, więc stały pakiet utrzymania nie zaczyna się od poznawania projektu od zera.

Typowy pakiet obejmuje listę prac utrzymaniowych, obsługę błędów i awarii, plan aktualizacji, wsparcie wydań, małe zmiany oraz doradztwo przy decyzjach: kiedy dopisać funkcję, kiedy przepisać fragment, kiedy przejść na własny zespół i kiedy nie warto ruszać działającej części systemu.

Jeśli aplikację zbudował inny dostawca, pierwszym krokiem jest rozpoznanie techniczne: repozytorium, zależności, publikacja, konta sklepów, narzędzia do zgłaszania awarii, architektura, testy, umowa techniczna i ryzyka kolejnych wersji. Dopiero potem ustalamy realny pakiet utrzymania.